先来参考文章：https://mp.weixin.qq.com/s/AHRCYOjnXAgcy2j6vziukQ?tdsourcetag=s_pctim_aiomsg

方案

一般情况下，MySQL分表会有几种方案：
1、初始点不同但是步数相同，比如A表起点是1步数是2，B表起点是2步数是2；
2、使用一个中间服务生成id，不再使用表自增，自己负责自增id；
3、使用UUID做id，就不怕冲突啦；
4、使用雪花算法做id，全数字还相对自增，一秒几百万种可能，就不怕冲突啦。

实际上，如果系统是新开发，推荐你是用雪花算法，因为uuid不能保证顺序性，而第一增加运维压力，第二个增加开发压力。

问题

问题来咯。
如果是旧系统，旧系统是自增id表，现在要分表怎么办呢？

我们每个方法预演一下：
1、旧表是单表，分表必定要根据业务id取模分到各个子表里面，那么大家的起点就会有问题，设置步长也是会冲突。除非手动将每个子表的maxid重新设置一个新的而且各个表的maxid是有序的，再去设置相同步长。这里涉及到运维成本！
2、新的中间服务，考虑可用性必须是分布式的，考虑线程安全必须做骚操作，开发成本！！！
3、呵呵了，人家int的主键被你这样一改，怕是代码都得重写吧。
4、同上。

所以说：旧系统是自增id表，分表要么运维成本，要么开发成本！

我肯定选择开发成本，因为步长法也有一个很大的缺点，不能保证有序性，A子表的id大，B子表的id小，但是实际上是A子表先插入的。

解决

解决方案：
1、留下一个表，一行参数。

|max_id|
|   100|

2、写一个生成id的服务，每次去表里面那max_id，然后虚拟出100个id在服务内部（后面业务要用的时候分配），再把max_id设置为200。

|max_id|
|   200|

3、为了保证可用性，这个生成id的服务是分布式的，有多个。

4、然后就出现并发问题了，每个服务同时取到了100，同时生成100个相同的id，同时去更新100为200.

5、解决办法，更新的时候做手脚，如果更新条数为0就重新拿id。

6、只要实施类似CAS乐观锁的思路（对比成功才替换的思路），在写回时对max-id的初始条件进行比对，就能避免数据的不一致，写回SQL由：

update T set max_id=200;
升级为：
update T set max_id=200 where max_id=100;

7、但是实际上上述是悲观锁，利用了mysql的排他锁机制，update语句会变成两条语句：

update T set max_id=200 where max_id=100;
变种为：
1、 a = select max_id from T where  max_id=100;//无锁
2、 update T set max_id=a.max_id where max_id=100;//排他锁

• 先执行第一句是无锁的，每个服务都拿到相同的a。
• 但是第二句是排它锁，只能有一个请求执行sql，第一个执行之后max_id就变了，那么后续的update语句都会执行条数为0.

8、如果update会自带排他锁，但是不能代表一定能够保证线程安全，需要有技巧的使用才行的，比如：
这里改成name。

update T set name =200 where max_id=100;
变种为：
1、 a = select name from T where  max_id=100;//无锁
2、 update T set name=a.name where max_id=100;//排他锁

大家拿到相同的a，第二条语句的max_id不变，就会所有线程都能成功执行update语句！！！