写在分库分表之前：真的走到这一步了吗？
引言
人是为了活着本身而活着的，而不是为了活着之外的任何事物所活着。
数据库也是如此，它本该安静地存着数据、吐着数据，而不是被业务增长的野心折腾得喘不过气来。
在写项目时，一道思考题拦住了我：
“随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，如何优化呢？”
项目给出的答案是分库分表。我的思绪开始盘旋——这样卸磨杀驴式的优化真的对吗？为了追求性能，把系统推上手术台，后续的维护该怎么办？
- 是不是要增加分布式事务，分布式ID？
- 分页，排序，聚合要怎么做？
- SQL是不是要重构？
- 数据如何迁移？
- 后续维护要怎么做？
真正的优化，应该是：根据对应场景，给出对应方案。
于是，我把常见的“数据库喘不过气”的症状，归为四种典型场景。每一种，都对应一次温柔的干预，而非粗暴的切割。
场景1：查询慢、CPU/IO爆表？先把SQL和索引抠到极致
数据量上来后，最先暴露的几乎都是查询慢。原因很简单：没有索引或SQL写得不好，数据库只能全表扫描，上亿行数据来回扫，IO和CPU直接爆表。
怎么做：开启慢查询日志，用EXPLAIN分析执行计划，在WHERE、ORDER BY、JOIN常用列建索引（优先复合索引），改掉SELECT *、嵌套子查询、OR、前缀LIKE等坏习惯，再用覆盖索引、分区表、调大innodb_buffer_pool_size。
为什么：索引把查询从O(n)全扫降到O(log n)精准定位，IO量往往减少90%以上，查询速度从秒级回到毫秒级。
注意：索引不是越多越好，过多会拖慢写入；定期清理冗余索引。
这一步做好，单表上亿行也能扛住，很多公司到这里就缓过气来了。
场景2：读多写少，高并发读把主库拖死？加缓存和读写分离扛住压力
SQL抠干净了，但读请求太多（刷列表、看详情），还是会把主库拖死。因为一台机器的读能力有限。
怎么做：热点数据放Redis缓存，主库写、从库读，一主多从，用中间件或代码路由读写分离。
为什么：缓存用内存读，命中率90%就能把数据库读负载降到1/10；读写分离再让读QPS翻几倍，轻松支撑日PV上亿。
注意：防缓存穿透（布隆过滤器）、雪崩（随机过期）、一致性问题（先写库后删缓存+延迟双删）；主从延迟敏感业务用半同步复制。
这一步是性价比最高的扩展方式，大多数系统走到这里就够用了。
场景3：写入频繁，主库QPS到顶、锁竞争严重？优化写入和事务解锁瓶颈
读的问题解决了，写开始密集，频繁加锁、长事务一多，主库QPS到顶，并发写入变慢。
怎么做：单条操作改批量，严格缩短事务长度，用小字段类型，热点表分区降低锁冲突。
为什么：批量把事务开销摊薄几倍到十几倍，短事务让锁更快释放，并发写能力大幅提升。
注意：监控长事务和死锁，代码里及时commit，避免一个慢事务拖垮全库。
这一步通常配合前两步，就能让写QPS再上一个数量级。
场景4：单表/单库太大，备份慢、存储爆？分库分表或分布式数据库突破极限
前三步都做了，单表还是几亿行、备份几小时、磁盘快爆，这时单库单表才真正到物理极限。
怎么做：先垂直拆分（按业务分库），再水平分表（按用户ID、时间等分片键拆表），用ShardingSphere等中间件；极端规模直接换TiDB、CockroachDB这类NewSQL。
为什么：数据和计算分散到多机，存储和性能都能线性扩展。
注意：跨库JOIN、事务、分页变麻烦，数据迁移复杂，扩容需谨慎选分片键（一致性哈希防热点）。不到万不得已别动这一步，复杂度会暴涨。
优化路径总结
- SQL + 索引
- 缓存 + 读写分离
- 写入和事务优化
- 分库分表/分布式数据库
结语
日子像一条河流，数据是河里的水，一天比一天多，一天比一天重。
我们总想不计代价地让它流得更快…