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

即使是不懂编程的玩家，在对比 NAS 的时候，也会两眼放光，考虑很多因素，比如 RAID 级别、速度、易用程度等。作为时时刻刻与代码打交道的我们，更需要关注数据的存取问题。

一开始，开箱即用的 MySQL，一定是企业的首选。不仅仅因为用的人多，更重要的是生态成熟。要工具有工具，要人有人。对于老板来说，员工看着不爽，可以随时辞退，是一个非常理想的状态。

但是，没有胸怀的老板，干的一定不会长久，因为如果商务会吹、老板会忽悠，业务会飞速发展（虽然现在这种机会比较少了）。对于 MySQL 来说，很快就会遇到问题。

这个时候，就需要一些比只会用 MySQL 级别高一些的人才，来配合老板圆梦。

是时候了，由单机 MySQL 向分布式发展了。

单机 MySQL 面临很多问题。

1. 单表太大，比如超过 500w，查询就非常吃力

2. 单库太大，各种资源告急

3. 读请求太高，严重影响写请求

对此，一堆概念也是腾空而出，比如分库分表、读写分离等。

很长时间以来，国内互联网的做法普遍是采用加入一个中间件的方式来解决，但随着分布式数据库的技术越来越成熟，这些魔法逐渐下沉到它本应该解决的层面--数据库实现层。

留给分库分表技术的时间，已经不多了，它的存量市场越来越少了。分库分表技术，退出历史舞台，也是迟早的事情了。

解决上面三个单机 MySQL 问题，有很多种切入层面。比如，你简单的在 MyBatis 或者 JPA 之上使用 A