共计 1364 个字符，预计需要花费 4 分钟才能阅读完成。
作者：毛辰飞
背景
在 mysql 中设计表的时候，mysql 官网举荐不要应用 uuid 或者不间断不反复的雪花 id(long 形且惟一)，而是举荐间断自增的主键 id，官网的举荐是 auto_increment，那么为什么不倡议采纳 uuid，应用 uuid 到底有什么害处？明天咱们就来剖析这个问题，探讨一下外部的起因。
数据展现
user\_auto\_key，user\_uuid，user\_random_key，别离示意主动增长的主键，uuid 作为主键，随机 key 作为主键，其它咱们齐全放弃不变。依据控制变量法，咱们只把每个表的主键应用不同的策略生成，而其余的字段齐全一样，而后测试一下表的插入速度和查问速度：
注：这里的随机 key 其实是指用雪花算法算进去的前后不间断不反复无规律的 id: 一串 18 位长度的 long 值
能够看出在数据量 100W 左右的时候,uuid 的插入效率垫底，并且在后续减少了 130W 的数据，uuid 的工夫又直线降落。
工夫占用量总体能够打出的效率排名为：auto\_key>random\_key>uuid，uuid 的效率最低，在数据量较大的状况下，效率直线下滑。
起因剖析
比照一下 mysql 对于两者索引的应用状况.
自增的主键的值是程序的, 所以 Innodb 把每一条记录都存储在一条记录的前面。当达到页面的最大填充因子时候(innodb 默认的最大填充因子是页大小的 15/16, 会留出 1 /16 的空间留作当前的批改)：
①下一条记录就会写入新的页中，一旦数据依照这种程序的形式加载，主键页就会近乎于程序的记录填满，晋升了页面的最大填充率，不会有页的节约
②新插入的行肯定会在原有的最大数据行下一行,mysql 定位和寻址很快，不会为计算新行的地位而做出额定的耗费
③缩小了页决裂和碎片的产生
因为 uuid 绝对程序的自增 id 来说是毫无法则可言的, 新行的值不肯定要比之前的主键的值要大, 所以 innodb 无奈做到总是把新行插入到索引的最初, 而是须要为新行寻找新的适合的地位从而来调配新的空间。这个过程须要做很多额定的操作，数据的毫无程序会导致数据分布散乱，将会导致以下的问题：
①：写入的指标页很可能曾经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb 在插入之前不得不先找到并从磁盘读取指标页到内存中，这将导致大量的随机 IO
②：因为写入是乱序的,innodb 不得不频繁的做页决裂操作, 以便为新的行调配空间, 页决裂导致挪动大量的数据，一次插入起码须要批改三个页以上
③：因为频繁的页决裂，页会变得稠密并被不规则的填充，最终会导致数据会有碎片
在把随机值（uuid 和雪花 id）载入到聚簇索引 (innodb 默认的索引类型) 当前, 有时候会须要做一次 OPTIMEIZE TABLE 来重建表并优化页的填充，这将又须要肯定的工夫耗费。
自增 ID 的毛病：
那么应用自增的 id 就齐全没有害处了吗？并不是，自增 id 也会存在以下几点问题：
①. 他人一旦爬取你的数据库, 就能够依据数据库的自增 id 获取到你的业务增长信息，很容易剖析出你的经营状况
②. 对于高并发的负载，innodb 在按主键进行插入的时候会造成显著的锁争用，主键的上界会成为争抢的热点，因为所有的插入都产生在这里，并发插入会导致间隙锁竞争
③. Auto_Increment 锁机制会造成自增锁的争夺, 有肯定的性能损失
