MySQL发号问题的分析和改进

　　这是学习笔记的第2253篇文章
　　读完需要
　　5hr分钟
　　速读仅需3分钟
　　关于发号器的使用，其实有一个大背景，那就是关于主键的一些设计问题，在MySQL中如果一张表没有主键，实际的数据处理就有点麻烦了。
　　因为在InnoDB存储引擎中，表都是按照主键的顺序进行存放的，我们叫做聚簇索引表或者索引组织表（IOT）
　　（1）显式的创建主键Primarykey。
　　（2）判断表中是否有非空唯一索引，如果有，则为主键。
　　（3）如果都不符合上述条件，则会生成UUID的一个隐式主键（6字节大）
　　可以使用类似的SQL来看到这个隐藏列，selectrowidfromtest；
　　这和主键有什么关系？主要是因为有些时候我们创建主键就是为了创建而创建，没有实际的业务含义，所以会形成一种使用习惯，那就是启用自增列。
　　自增列的问题很多，有些几句话还说不清楚，大体有如下的一些问题
　　自增列没有业务含义
　　过度依赖自增列
　　自增列和状态值主键并存，反而影响业务逻辑和性能
　　MySQL历史遗留bug，在MySQL8。0该问题才修复
　　到了这里，我们的需求也基本明确了，我们所说的发号器其实就是要确保每次取到的ID号都是唯一的，当然也显而易见是趋势递增的。
　　我来说一个初版的发号器实现，假设我们创建一张表testinc，假设按照业务逻辑，自增列的初始值为1000，则建表语句为：createtabletestinc（idintprimarykeyautoincrement，flagvarchar（20））engineinnodbautoincrement1000；altertabletestincmodifyflagvarchar（20）unique；
　　建表语句为：mysqlshowcreatetabletestincG1。rowTable：testincCreateTable：CREATETABLEtestinc（idint（11）NOTAUTOINCREMENT，flagvarchar（20）DEFAULT，PRIMARYKEY（id），UNIQUEKEYflag（flag））ENGINEInnoDBAUTOINCREMENT1000DEFAULTCHARSETlatin1
　　使用replaceinto的逻辑来进行id的初始化：replaceintotestinc（flag）values（1）；
　　数据结果为：mysqlselectfromtestinc；idflag10001rowinset（0。00sec）
　　mysqlreplaceintotestinc（flag）values（1）；QueryOK，rowsaffected（0。01sec）
　　mysqlselectfromtestinc；idflag10011rowinset（0。00sec）
　　得到当前的写入id值为：mysqlselectlastinsertid；lastinsertid1001rowinset（0。00sec）
　　按照这个逻辑在多会话并发中依然可以得到期望中的ID自增效果，这些也是lastinsertid本身的功能范围，就不再赘述了。
　　但是这种方案在RDS环境中会碰到一个很尴尬的问题，那就是RDS的服务会做内部切换，而切换后的ID值就会重置。
　　假设从库的id当前值为1002，在从库切换后，会提升为主库，即可以实现读写，那么在新主库上执行replaceinto语句结果就会让人奇怪，完整的模拟过程如下：mysqlselectfromtestinc；idflag1002rowinset（0。00sec）
　　mysqlreplaceintotestinc（flag）values（1）；QueryOK，rowsaffected（0。02sec）
　　mysqlselectfromtestinc；idflag1001rowinset（0。00sec）
　　mysqlselectlastinsertid；lastinsertid1001rowinset（0。00sec）
　　碰到这种情况就很尴尬了。好端端的自增ID一下子被打回了原形，而如果结合主从复制的过程和replaceinto的逻辑，其实也不难分析出这个问题。
　　简而言之，对于自增列的使用，在如上的场景中是不能够胜任ID自增的逻辑的，可能会产生断层，我们可以通过别的方式来实现。
　　在数据库中不难发现这样的设计成平，比如Oracle里面的sequence就是一个例子。
　　我们干脆来实现下这个sequence的简单逻辑吧。mysqlcreatetablesequence（idintprimarykeyautoincrement）；QueryOK，0rowsaffected（0。05sec）
　　mysqlinsertintosequencevalues（lastinsertid）；QueryOK，rowaffected（0。01sec）
　　接下来需要做两类场景的测试，
　　验证方法一样：mysqlselectfromsequence；id1003rowinset（0。00sec）
　　mysqlupdatesequencesetidlastinsertid（id）；QueryOK，rowaffected（0。00sec）Rowsmatched：1Changed：1Warnings：0
　　mysqlselectfromsequence；id1004rowinset（0。00sec）
　　mysqlselectlastinsertid；lastinsertid1004rowinset（0。00sec）
　　一种是多会话状态下验证ID自增的情况，使用lastinsertid
　　另外一种则是在从库端直接刷新验证，通过测试可以快速验证得到这种方式的可行性。
　　当然这个还没有考虑复杂的并发场景，如果想提高吞吐量，可以考虑分布式ID的玩法。