这是阿里的开发手册上写的
单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
曾经在中国互联网技术圈广为流传着这么一个说法
MySQL 单表数据量大于 2000 万行，性能会明显下降。事实上，这个传闻据说最早起源于百度。
也有人说（这种说法没法证明出处）
当单表的数据量达到 1000W 或 100G 以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。
无论是 500 万、1000 万还是 2000 万，个人认为还是要根据自己应用的实际情况来看。
也许你的应用在单表 500 万性能就下降的很厉害，那就赶紧想办法。也许 500 万没啥事儿也要提前规划了，想清楚数据增量有多少，提前做好容量和架构规划。
从业务上讲，一般都是读多写少，而我们知道写是有锁的，写多了查询自然也慢，当然写多了证明业务发展的好，也是件好事，比如订单量上来了。
所以我们可以通过读写分离来分离读和写，让两边的执行效率都提升上来。但也只是在一定程序上缓解了，因为读写分离分散了读写操作的压力，但没有分散存储的压力，当数据量达到千万级以上的时候，单台数据库服务器的存储能力就会成为瓶颈。
从解决方案的角度，我们综合考虑使用 ShardingSphere-JDBC 的�方案，其实 ShardingSphere-Proxy 的方案也可以，但由于需要做高可用，对于架构的复杂性有所提升就放弃了，还是用基于 jar 包的 ShardingSphere-JDBC 的方案比较合适。
1 主从库同步延时
同步不及时会导致写到主�库的数据从库读不到。从用户应用的角度讲，就算这种情况，一般也没什么问题，查不到嘛？再查一次数据就同步了。延时不至于那么久。（比如某云厂商告诉我他们的同步延时在 1 秒以内）
但是从程序执行的角度可能就会有问题，程序执行是很快的，如果数据没有同步，瞬时执行了 N 行代码就可能会报错。不过只要容错处理好，问题也不大，重试一次就好了。或者有这种逻辑的程序强制路由到主库。