mysql分库分表，分布式id生成器的意义

• 可以使用主键进行删改查

大型系统架构时，最推荐的就是使用主键查询，和以前在猫眼的同事聊过，他们使用数据库有规定，只能通过主键删改查数据，稍微复杂点的sql是不允许使用的，甚至连连接查询都被禁止使用的。

• 绝对不能使用自增id

绝大多数程序员在使用mysql时都会使用自增主键，但是它的自增仅仅是适合单机版的，如果项目后期要涉及到分库分表，自增Id的维护成本会非常大，所以在设计数据库之初，分库分表的需求一定要考虑进去

比如，在开始你做2个分表，那么这个自增长id的步长设置为2

第一个表，它的id可以是：1,3,5,7,9

第二个表，它的id可以是：2,4,6,8

这样看起来是可以玩的，但是数据库表再进行扩展，加2张表，你的id怎么做，改变步长？修改数据？等等都会是非常头疼的事

• 分库分表时，主键应该怎么处理

首先，分库分表，我们一般考虑的是 Hash 键，它不一定要用表的主键，但是，很多时候直接就拿主键来用了。

其次，“自增”这东西，只是现象，不是实现方式。正常点的关系数据库（Postgresql，Oracle之类的），都有 sequence ，序列这个机制，“自增”只是帮你定义了一个 sequence ，每次取值都从序列当中取一个，值是什么，就是序列怎么实现的事了。 MySQL 没有序列，问题就麻烦了。

在有序列机制的情况下，分表根本不是事，当要让多表使用同一个序列就可以了，对吧。

分库的话，就一定需要引入外部的“序列生成器”了。

Hash 键的处理是分库分表的基础，不是一个用不用自增 ID 这么简单的一个点的了。而且，一个专门的解决方案，暴露给使用者的，主键上其实也是“自增 ID”，只是它这个的“序列生成器”肯定不是系统默认自带的那套了嘛

• 最幸福的主键

在大型电商架构中，订单id都是由订单系统生成，然后下游系统接消息，对订单处理，比如仓储系统，会通过调度系统接收到订单及订单详情，这时候的Id已经由上游系统生成完成，我们只需要做消息幂等性处理，就可以很easy的将订单数据分别入到对应的数据库中