本篇为个人整理笔记
1.背景
使用MySQL的Innodb引擎，在建表时，对于主键应该怎么选择产生了一些问题，如何建立一个合理的主键，能够在数据增长时不会造成索引分裂和磁盘碎片，并且能保证在分布式系统下的唯一性。
2.结论
非分布式架构直接套用自增id做主键
小规模分布式架构用uuid或者自增id+步长做主键
大规模分布式架构用自建的id生成器做主键
3.业务系统对ID号的要求
- 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
- 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
- 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
- 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。
ID生成系统的要求
- 平均延迟和TP999延迟都要尽可能低
- 可用性5个9
- 高QPS
4.各种方案介绍
4.1 自增id
优点
- 主键页以近乎顺序的方式填写，提升了页的利用率
- 索引更加紧凑，性能更好查询时数据访问更快
- 节省空间
- 连续增长的值能避免 b+ 树频繁合并和分裂
- 简单易懂，几乎所有数据库都支持自增类型，只是实现上各自有所不同而已
缺点
-
可靠性不高
存在自增ID回溯的问题，这个问题直到最新版本的MySQL 8.0才修复。 -
安全性不高
ID不够随机，对外暴露的接口可以非常容易猜测对应的信息。比如：/User/1/这样的接口，可以非常容易猜测用户ID的值为多少，总用户数量有多少（泄露发号数量的信息），也可以非常容易地通过接口进行数据的爬取，因此不太安全。 -
性能差
自增ID的性能较差，需要在数据库服务器端生成。对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争。 -
交互多
业务还需要额外执行一次类似2867811的函数才能知道刚才插入的自增值，这需要多一次的网络交互。在海量并发的系统中，多1条SQL，就多一次性能上的开销。 -
局部唯一性
最重要的一点，自增ID是局部唯一，只在当前数据库实例中唯一，而不是全局唯一，在任意服务器间都是唯一的。对于目前分布式系统来说，这简直就是噩梦。 -
不利于数据迁移与扩展
不适合以自增ID主键作为主键的情况
- 数据量多需要分库分表，可能会造成ID重复
- 经常会遇到数据迁移的情况
- 新数据需要和老数据进行合并
4.2 UUID
介绍
UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前为止业界一共有5种方式生成UUID，详情见IETF发布的UUID规范 A Universally Unique IDentifier (UUID) URN Namespace**
优点
- 性能非常高：本地生成，没有网络消耗。
缺点
-
不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
-
信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
-
对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。
4.3 类snowflake方案
介绍
这种方案大致来说是一种以划分命名空间（UUID也算，由于比较常见，所以单独分析）来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示
理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
优点
- 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
- 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
- 可以根据自身业务特性分配- 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。bit位，非常灵活。
缺点
- 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
