数据库主键全局唯一方案

现在通过数据的水平切分（sharding）来实现数据库 Scale Out 的解决方案受到了越来越多人的青睐，但是在切分过程中可能遇到的问题也肯定不在少数，如切分规则的设计，切分后的访问路由，切分后的主键的全局唯一等等。

这里我主要列举几个可以使用在 MySQL 数据库主键全局唯一方案及其优劣，供大家参考：

• 通过应用程序生成一个GUID，然后和数据一起插入切分后的集群。优点是维护简单，实现也容易。缺点是应用的计算成本较大，且GUID比较常，占用数据库存储空间较大，涉及到应用的开发。

说明：主要优势是简单，缺点是浪费存储空间，GUID：32字节，100W记录，多32兆，如果是int，4字节，会少28M。如果有外键关联，会浪费更多。

• 通过独立的应用程序事先在数据库中生成一系列唯一的 ID，各应用程序通过接口或者自己去读取再和数据一起插入到切分后的集群中。优点是全局唯一主键简单，维护相对容易。缺点是实现复杂，需要应用开发。 说明：ID表要频繁查和频繁更新，插入数据时，影响性能。

• 通过中心数据库服务器利用数据库自身的自增类型（如 MySQL的 auto_increment 字段），或者自增对象（如 Oracle 的 Sequence）等先生成一个唯一 ID 再和数据一起插入切分后的集群。优点是？好像没有特别明显的优点。缺点是实现较为复杂，且整体可用性维系在这个中心数据库服务器上，一旦这里crash 了，所有的集群都无法进行插入操作，涉及到应用开发。 说明：不推荐。

• 通过集群编号加集群内的自增（auto_increment类型）两个字段共同组成唯一主键。优点是实现简单，维护也比较简单，对应用透明。缺点是引用关联操作相对比较复杂，需要两个字段，主键占用空间较大，在使用 InnoDB 的时候这一点的副作用很明显。 说明：虽然是两个字段，但是这方式存储空间最小，仅仅多了一个smallint两个字节，100W也就多2M。

• 通过设置每个集群中自增 ID 起始点（auto_increment_offset），将各个集群的ID进行绝对的分段来实现全局唯一。当遇到某个集群数据增长过快后，通过命令调整下一个 ID 起始位置跳过可能存在的冲突。优点是实现简单，且比较容易根据 ID 大小直接判断出数据处在哪个集群，对应用透明。缺点是维护相对较复杂，需要高度关注各个集群 ID 增长状况。 说明：段满了，调整太麻烦。

• 通过设置每个集群中自增 ID 起始点（auto_increment_offset）以及 ID 自增步长（auto_increment_increment），让目前每个集群的起始点错开 1，步长选择大于将来基本不可能达到的切分集群数，达到将 ID 相对分段的效果来满足全局唯一的效果。优点是实现简单，后期维护简单，对应用透明。缺点是第一次设置相对较为复杂。 说明：避免重合需要多种方案结合

摘自: