很多人搞不清分库和分表的区别，其实很简单：

分表 是为了解决单表数据量太大导致的查询慢问题。

分库 是为了解决单机数据库的连接数、写入能力和存储空间的物理上限问题。

简单说：数据量大就分表，写入压力大就分库。

什么时候该考虑分库分表？

别凭感觉，看这几个硬指标。满足任意1-2项，就该认真评估了。

 1. 单表数据量超过1000万～2000万行

或者单表文件大小超过50GB。这时候B+树索引层级会加深，查询肯定变慢。优先考虑分表。

 2. 单表写入QPS持续超过3000

写入太快，行锁、页锁竞争激烈，插入会越来越慢。优先考虑分表。

 3. 数据库连接数接近上限

MySQL默认连接数只有151，连接不够用，新请求就没法处理。优先考虑分库。

 4. 磁盘使用率超过80%

磁盘读写延迟会急剧增加，甚至容量耗尽。优先考虑分库。

 5. 有业务隔离需求

不同业务或租户需要物理隔离，保障核心业务稳定。优先考虑分库。

注意：这些数值不是绝对的，和服务器配置、SQL写法、单行数据大小都有关系。比如一张只有int和短varchar的表，2000万行可能还很轻松。

从现象倒推：到底是分库还是分表？ 数据量大，但写入不高

比如历史数据表、日志表。主要问题是单表太大，查询慢。这时候分表是主要手段，比如按月分表，能有效缩小查询范围。

 写入量很高

比如订单表、流水表。主库的写入压力是瓶颈。分库可以把写压力分散到多个主库上，提升整体写入能力。

 数据量和写入量都高

比如大型电商的订单表。这就需要分库分表结合，常见做法是先按user_id分库，再在库内按时间分表。

最重要的问题：真的必须分吗？

分库分表是架构演进的大手术，牵一发而动全身。动手前，先确认这些更简单、成本更低的手段是否已经用尽。

优化索引 ：是不是所有SQL都走了最优索引？一个糟糕的查询，在千万级数据上就能拖垮数据库。

优化SQL ：有没有SELECT *、LIKE '%xxx%'这样的低效SQL？

升级硬件 ：换成内存更大、IOPS更高的SSD硬盘，往往能直接解决问题。

读写分离 ：如果读请求占比很大，搭建主从+读写分离可能就足够了，成本远低于分库分表。

数据归档 ：对于一些历史数据，是否可以直接迁移到冷存储？

只有当以上手段都试过，仍无法满足业务需求时，再启动分库分表的方案。

结束语

分库分表是数据库性能优化的重要手段，但不是银弹。

先搞清楚问题到底出在哪：是数据量大，还是写入压力大？

再评估是否有更简单的解决方案。最后才考虑分库分表。

​

阅读原文：https://mp.weixin.qq.com/s/3BV6cJP0PuERqda-nH_n6g