标签: 分库分表

分库分表在很多团队是一种默认操作：数据量一大就分。但它换来的收益很窄，付出的代价很宽，而且代价大多在上线半年后才开始显现。 先问要不要分 分库分表真正解决的问题只有两个：单表数据量导致的索引效率下降，以及单库写入的 IOPS 瓶颈。除此之外的问题它都解决不了，甚至会恶化。 在决定分之前，这几件事的性价比更高： 加索引或改查询。慢查询里相当大一部分是索引缺失或者写法导致索引失效，跟数据量无关。 冷热分离。交易流水表里九成查询集中在最近三个月。把历史数据归档到历史库，主表立刻瘦身，成本远低于分表。 …

当单表涨到几亿行、单库连接打满，分库分表就从「可选项」变成「生存项」。但分片一旦定错键，后期重构的代价接近重写。所以策略要在一开始就想清楚。 分片键是第一步，也是最重要的一步 分片键决定数据怎么散、请求怎么走。选错键，要么数据倾斜，要么跨分片查询泛滥。 选高频等值查询字段：比如账户号、客户号，保证大多数请求落单分片。 避免低基数或单调递增：性别这种分片键会制造大分片；自增 ID 做键会集中在最新分片，形成写入热点。 兼顾关联查询：同一客户的账户、交易最好同片，减少跨片 JOIN。 -- 按客户号 …