什么时候应该分库分表？

答：
你的系统刚上线，用户量和请求量都不高，那么单个数据库就足够了；随着业务的不断发展，用户量越来越多，高峰期每秒的并发量达到3000多，此时单个数据库已经很吃力了；业务还在继续发展，并发也越来越高。此时应该进行数据库拆分，如果1个数据库的并发是每秒4000，那么10个数据库的并发是每秒40000。
如果你的单表的数据量已经到达1000万了，那么应该考虑分表了，单表数据量大的话执行sql就会变的很慢。

分库和分表可以分开进行，如果你需要提高并发，那么需要进行分库；如果你的并发不高，但是你的表数据量很大，那么需要进行分表；如果你的并发很高，数据量也很大，那么需要分库分表。

什么是分库？

答：
1）垂直拆分
就是把数据库里面的表，按照业务进行拆分，比如：订单模块，消息模块分别使用不同的数据库。

2）水平拆分
就是把相同数据库拆分为多个，里面的表都是一样的。减少数据库磁盘大小；数据库命名为order_center_0，order_center_1，order_center_2；

什么是分表？

答：
1）垂直拆分
把一个大表拆分为两个表，把经常使用的字段和不太使用的字段分开，如：user，user_profile；比较常用的字段在user表，大字段和不太常用的字段放在user_profile表；

2）水平拆分
把相同结构的表拆分为多个，把数据分散存储在不同的表里面，如：user_0,user_1,user_2；数据分散在不同的表里；减少单表的大小；

分库分表的方式？

答：
1）随机分片：如hash法
好处：可以平均分配没给库的数据量和请求压力；
坏处：扩容起来比较麻烦，会有一个数据迁移的这么一个过程。

2）连续分片：如自然月分法、数字范围法
好处：后面扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；
缺点：但是大部分的请求，都是访问最新的数据，热点数据成为性能瓶颈。实际生产用自然月，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据；

用过哪些分库分表中间件？他们的优缺点？

答：
框架大概有：cobar、TDDL、atlas、sharding-sphere、mycat
目前比较常用的是：sharding-sphere、mycat；

目前中间件主要分：client层和代理层
client层：在项目里引入jar包，用代码来控制分库分表的策略。
代表：sharding-sphere
1）优点：不用部署额外系统，运维成本低，不需要代理层二次转发性能高。
2）缺点：对系统有耦合。

代理层：需要在数据库和应用层中间部署服务，所有的策略都在代理层自己完成。
代表：mycat
1）优点：对应用层是透明的，没有侵入性。
2）缺点：增加维护成本，需要额外部署系统，降低系统高可用（代理层挂掉了）。

这里推荐使用sharding-sphere；
因为支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）；Sharding-Proxy现在也支持代理层了。

图片来自sharding-sphere官网

id生成策略？

答：
使用了分库分表之后，id自增就不行了，需要有一个全局唯一的id。
1）、Twitter的Snowflake （推荐）
好处：分布式；单机是自增的；性能高；每个机器配置不一样的机器码就可以保证唯一；
缺点：分布式下因为时间不一致，可能会出现不自增情况；

2）、UUID
好处：唯一；性能高；
缺点：不可读；不是自增；
一般不推荐使用

3）、redis的INCR
好处：天然自增；性能高于数据库；可以实现负载；
缺点：没有redis需要引入redis；配置成本增加；

4）、id服务系统
好处：统一管理id；
缺点：所有系统都调用，访问压力大；

引入分库分表之后会引出什么新问题？

答：
1、事务一致性问题；
2、跨节点Join问题；
3、跨节点排序、分页、函数使用问题：如count、order by等；
4、数据迁移、扩容；