分库分表的原因无非就是：一、单库并发太高；二、单库数据量太大。

解决方案：

方案一：基于单库的自增ID，拿到这个ID之后再往分库分表里写入。

适用场景：适用于并发不高，数据量太大的场景。

方案二：设置数据库sequence或者表自增字段步长。

例如：现在有8个服务节点，每个服务节点使用一个sequence功能产生一个ID，每个sequence的其实ID不同，并且一次递增，步长都是8.

适用的场景：这种方案实现起来比较简单，也能达到性能的目标。但是服务节点固定，步长也固定，将来如果还要增加服务节点，就不好搞了。

方案三：UUID：不建议适用UUID做主键。

好处：本地生成，不基于数据库生成。

缺点：UUID太长、占用空间太大、作为主键性能太差、不具有有序性。

方案四：系统时间+业务字段拼接组成主键ID。

1、选择唯一性索引；

2、为经常需要排序、分组和联合操作的字段建立索引；

3、为常作为查询条件的字段建立索引；

4、限制索引的数目；

5、尽量使用数据量少的索引；

6、尽量使用前缀来索引；

7、删除不再使用或者很少使用的索引；

8、最左前缀匹配原则，非常重要的原则；

9、=和in可以乱序；

10、尽量选择区分度高的列作为索引；

11、索引列不能参与计算，保持列“干净”；

12、尽量的扩展索引，不要新建索引。

解决办法：通过在主库中创建一个流水表，把操作数据库的逻辑映射为一条流水记录。当整个大事务执行完毕后（流水被插入到流水表）,然后通过其他方式来执行这段流水，保证最终一致性。

注：本解决方法是基于非事务消息的异步确保的方式来完成分库分表中的事务问题。

脏读：脏数据所指的就是未提交的数据。也就是说，一个事务正在对一条记录做修改，在这个事务完成并提交之前，这条数据是处于待定状态的（可能提交也可能回滚），这时，第二个事务来读取这条没有提交的数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被称为脏读。

不可重复读（Non-Repeatable Reads）：一个事务先后读取同一条记录，而事务在两次读取之间该数据被其它事务所修改，则两次读取的数据不同，我们称之为不可重复读。

幻读（Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为幻读。解决幻读的方法是增加范围锁RangeS，锁定检索范围为只读，这样就避免了幻读。

三者到底什么区别：

脏读：指读到了其他事务未提交的数据。

不可重复读：读到了其他事务已提交的数据(update)。

不可重复读与幻读都是读到其他事务已提交的数据,但是它们针对点不同。

不可重复读：update。

幻读：delete，insert。