分库分表经常被当成高并发系统的标准答案，但它不是越早做越好。真正应该先回答的问题，是现有瓶颈到底来自容量、吞吐还是业务隔离需求。
先分清垂直拆分和水平拆分
按业务领域拆库、按字段拆表，更偏向垂直拆分；按用户、订单号或时间维度做数据切分，则更偏向水平拆分。两者解决的问题并不一样。
拆分前先确认单库是否真的到瓶颈
如果索引、SQL、缓存和冷热分层还没做好，直接上分库分表往往只是把简单问题复杂化。能在单库阶段解决的，优先别过早拆分。
拆完之后最麻烦的是一致性和查询
跨库事务、分页排序、聚合查询和全局唯一 ID 都会变复杂。面试里如果只说“能扩容”，没有提这些代价，答案通常不完整。
路由规则必须长期稳定
无论按用户还是按时间分片，路由键一旦选错，后面迁移和扩容都会很痛苦。这个取舍往往比具体中间件名字更关键。
结论
分库分表不是默认选项，先想清楚瓶颈、拆分方式和后续代价，再决定是否真的值得做。
正文完
