分库分表策略与热点治理

当单表涨到几亿行、单库连接打满，分库分表就从「可选项」变成「生存项」。但分片一旦定错键，后期重构的代价接近重写。所以策略要在一开始就想清楚。

分片键是第一步，也是最重要的一步

分片键决定数据怎么散、请求怎么走。选错键，要么数据倾斜，要么跨分片查询泛滥。

• 选高频等值查询字段：比如账户号、客户号，保证大多数请求落单分片。
• 避免低基数或单调递增：性别这种分片键会制造大分片；自增 ID 做键会集中在最新分片，形成写入热点。
• 兼顾关联查询：同一客户的账户、交易最好同片，减少跨片 JOIN。

-- 按客户号哈希分 1024 片
SELECT * FROM trans_${hash(cust_id)%1024}
WHERE cust_id = ? AND trans_date >= ?;

扩容：预分片优于临时拆

一开始就按「未来三年规模」定足够多的逻辑分片（如 1024、4096），物理上先少后多。扩容只是把逻辑分片映射到新物理库，数据迁移量远小于重新分片。

// 逻辑分片到物理库的映射可配置
String logic = "trans_" + (hash(custId) % 1024);
String phys  = routeTable.lookup(logic); // 映射到具体物理库

热点治理

即使哈希均匀，业务上仍会有「明星账户」「大商户」成为单点热点。

• 二级分片：对超大 key 再按时间或子维度拆。
• 读写分离 + 缓存：把热点读打到只读副本或缓存。
• 限流与隔离：热点账户单独队列，避免拖垮整片。

分库分表解决的是「装得下」，热点治理解决的是「扛得住」。两者都做，系统才既大又稳。

最后提醒：分片后事务、全局唯一 ID、跨片聚合统计都要重新设计，别等上线才发现漏了。分布式 IDs 建议用号段或雪花算法，跨片统计要么预聚合、要么上 OLAP 旁路，不要把在线事务库当报表库用。