分片策略

单库单表扛不住写入与存储时，需要 分片（Sharding）：把数据按规则拆到多个物理节点。分片解决容量与写扩展，但带来跨片查询、热点与再平衡等新问题——building-for-scale 数据层的核心课题。

学习目标

• 对比范围分片、哈希分片、目录分片的优缺点
• 识别热点分片（Hot Shard）成因与缓解手段
• 理解再平衡（Re-sharding）对业务的影响与迁移策略

核心概念

策略	规则示例	优点	风险
范围分片	user_id 1–1M → 片 A	范围查询友好	新用户挤在最后一片
哈希分片	hash(user_id) % N	分布均匀	扩片需 rehash
目录分片	映射表查片号	灵活迁移	映射表成单点

shard_key = user_id
shard_id  = hash(user_id) mod 16
          → 写入 db-shard-07

选片键（Shard Key）原则：

1. 高基数、分布均匀（避免全站用户按 country=CN 一片）
2. 与主要查询条件一致（按 user_id 查订单，片键含 user_id）
3. 尽量避免跨片事务（用 Saga / 最终一致替代）

热点：大 V 用户、秒杀商品会让单片 QPS 爆表。缓解：片内再分、热点数据缓存、写队列串行化。

再平衡常用 双写 + 灰度切读 或 一致性哈希 减少迁移量。ORM 层分片见 orm-essentials；PostgreSQL 分区表见 postgresql-essentials。

练习

• 为订单表选择 shard key，写出两条 SQL 是否需跨片
• 估算从 8 片扩到 16 片时，至少多少数据行需要迁移
• 讨论：全局自增 ID 在分片下如何生成（雪花算法 / DB 号段）

小结

分片让数据横向生长，但片键与再平衡设计错了，扩展会比不分片更痛。