分库分表和NewSQL，哪种方案更适合我的系统需求？

本文共计3793个文字，预计阅读时间需要16分钟。

曾经，分库分表和数据量大就分表已成为处理MySQL数据增长问题的经典做法。面试官喜欢问，博主喜欢写，而旁观者也乐于评论，似乎形成了一个闭环。但你是否思考过，这些做法是否真的有效？

曾几何时，“并发高就分库，数据大就分表”已经成了处理 MySQL 数据增长问题的圣经。

面试官喜欢问，博主喜欢写，候选人也喜欢背，似乎已经形成了一个闭环。

但你有没有思考过，分库分表真的适合你的系统吗？

分表

在业务刚刚发展起来的时候，流量全部打到了一个 MySQL 上，用户信息全落到了 user 表。

后来，user 表的数据量越来越大了。

于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user_details 表。

这样一拆之后，用户的信息分散到两个表，user 表的数据量一下就变小了，user 表数据量过大的问题暂时就解决了。

但随着业务的发展，线上的流量越来越大，单个 MySQL 已经扛不住流量的压力了。

单个库承受不住压力的时候，就需要分库了。

分库

顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。

拆成多个库也意味着进行了分表，也就是说分库一定分表，分表不一定分库。

我们可以根据_偏应用_还是_偏 DB_，将分库分表的实现方式分成三种类型：

• JDBC 代理模式

• DB 代理模式

• Sharding On MySQL 的 DB 模式

JDBC 代理模式

JDBC 代理模式是一种无中心化的架构模式。