分库分表策略与热点治理

Mon, 30 Mar 2026 00:00:00 +0000

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

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

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

-- 按客户号哈希分 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); // 映射到具体物理库

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