曾几何时，“并发高就分库，数据大就分表”已经成了处理 MySQL 数据增长问题的圣经。
面试官喜欢问，博主喜欢写，候选人也喜欢背，似乎已经形成了一个闭环。
但你有没有思考过，_分库分表真的适合你的系统吗？_
分表
在业务刚刚发展起来的时候，流量全部打到了一个 MySQL 上，用户信息全落到了 user 表。
后来，user 表的数据量越来越大了。
于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user\_details 表。
这样一拆之后，用户的信息分散到两个表，user 表的数据量一下就变小了，user 表数据量过大的问题暂时就解决了。
但随着业务的发展，线上的流量越来越大，单个 MySQL 已经扛不住流量的压力了。
单个库承受不住压力的时候，就需要分库了。
分库
顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。
拆成多个库也意味着进行了分表，也就是说分库一定分表，分表不一定分库。
我们可以根据_偏应用_还是_偏 DB_，将分库分表的实现方式分成三种类型：
- JDBC 代理模式
- DB 代理模式
- Sharding On MySQL 的 DB 模式