分库分表可能真的要退出历史舞台

背景

一开始，开箱即用的 MySQL，一定是企业的首选。不仅仅因为用的人多，更重要的是生态成熟。随着业务的飞速发展（虽然现在这种机会比较少了），对于 MySQL 来说，很快就会遇到各种性能问题。这个时候，就需要由单机 MySQL 向分布式发展了。

传统数据库的瓶颈

单机 MySQL 面临很多问题：

• 单表太大，比如超过 500w，查询就非常吃力
• 单库太大，各种资源告急
• 读请求太高，严重影响写请求

传统数据库解决方案

很长时间以来，国内互联网的做法普遍是采用加入一个中间件的方式来解决，但随着分布式数据库的技术越来越成熟，这些魔法逐渐下沉到它本应该解决的层面 – 数据库实现层。留给分库分表技术的时间已经不多，它的存量市场越来越少了。分库分表技术，退出历史舞台，也是迟早的事情了。解决上面三个单机 MySQL 问题，有很多种切入层面，常见的有框架层、驱动层、代理层。

第一种（框架层）

简单地在 MyBatis 或者 JPA 之上使用 AOP 或者拦截器封装一层，也可以实现，这也是最傻的方式。

第二种（驱动层）

再进一步，就可以在 JDBC 之上的驱动层来实现，把分库分表的路由维护在内存里，通过重写的 DataSource、Connection、Statment、ResultSet 等，对业务进行无侵入的改进。但可惜的是，这类方案还必须要维护与逻辑表相对应的物理表，而且功能也是阉割的，不确定性依然不小。更要命的是，JDBC 只支持 Java，对于某些公司来说，就非常的不适用。

第三种（代理层）

再就是采用中间件的传统模式，引入 Proxy 中间件，即把自己伪装成一个 MySQL Server，接受 Client 的请求。至于它后面怎么去操作真实的数据库，开发者都不需要知道。但 Proxy 本身也是一套服务，需要保证高可用，且有运维成本在里面，同时功能依然是阉割的。

新型数据库解决方案

框架层、驱动层、代理层，在过去很长一段时间里，有无数的互联网公司前赴后继的试水，从 TDDL、Cobar，到 MyCat、ShardingSphere，各种层面的中间件也是层出不穷。但最近几年，这种争相斗艳的场面逐渐不再，到最后剩下来的，也就 ShardingSphere 这一枝独秀了。是问题不存在了么？不，正好相反，问题越来越严重。并不是问题消失了，而是它被转化成其他解决方式了。

分布式数据库的前景

抛开关系型数据库不说，很久之前，类似于 ElasticSearch、Cassandra 这样的 NoSQL 存储，分片和副本的概念，就已经非常成熟了，而且它们是内置的，并不需要 DBA 去人工维护它们的物理位置。对于关系型数据库来说，走向分布式也终将成为必然。随着 Raft 等协议应用越来越广泛，分布式数据库的可靠性也逐渐得到了保证。如果以前因为事务问题而拒绝采用某些 NoSQL 产品，那么如今完全兼容 MySQL 的分布式数据库，没有理由再拒绝。

分布式数据库的选择

云厂商，直接提供了像 Aurora、PolarDB 之类的 MySQL 增强，更有类似 TiDB、OceanBase 这样纯粹的分布式数据库，越来越多的业务走向了这个终途。当团队加班加点验证着分库分表中间件的时候，却发现其实换个兼容的存储就能玩得转，你会怎么选，简直不用再多说。当然，一旦选用了分布式数据库，以前的 DBA 经验可能就不管用了，比如说索引及其二级索引。开发团队不得不学习新的知识，来应对分布式环境。但这些都是阵痛，长远看来，分布式数据库是趋势，而分库分表中间件只能吃存量业务。

如何选择解决方案

• 如果业务拥有常年累积的大量复杂数据，建议采用复杂的分库分表组件。
• 如果业务比较新，在可预见的未来会有大量数据，那选择分布式数据库是最合适的。

最后总结

分库分表中间件并不是消失了。它摇身一变，变成了分布式数据库的一部分。你可能会听到很多切到分布式数据库，又从分布式数据库切回到 MySQL 的案例，这属于想吃螃蟹但并没有吃到。目前来看，分布式数据库越来越稳定，生态建设也越来越好。而分库分表，则适用于存量业务，终将会退出历史的舞台。