数据库“分库分表”属于架构演进后期的手段，通常不是一开始就做，而是在单体/单库已经无法满足业务或性能需求时才考虑。下面从触发信号、数据量级、业务特征、成本与替代方案几个维度说明“何时需要做”。
在决定分库分表前，通常应先尝试以下“更轻量的方案”：
如果以上都做了，瓶颈仍在，才考虑分库分表。
| 类型 | 解决什么问题 |
|---|---|
| 分表 | 单表数据量过大，查询/写入变慢 |
| 分库 | 单实例连接、CPU、IO 达到上限 |
| 分库+分表 | 数据量和并发都到极限 |
注：不是绝对标准，取决于表结构、索引、QPS
出现以下情况之一：
以下场景“天然适合”分库分表：
分片键选择原则：
❌ 数据量小但“觉得以后会大”
❌ 为了“架构好看”提前分
❌ 团队没能力维护分布式事务、路由、扩容
分库分表会显著增加：
- 开发复杂度
- 跨分片查询难度
- 分布式事务成本
当单库单表在“优化 + 读写分离 + 缓存”后仍无法满足性能或容量需求，且数据量/并发明确进入千万级、TB 级时，才考虑分库分表。
如果你愿意，可以告诉我：
我可以帮你判断是否“现在就该做”，还是“再撑一阵”。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
