分片是数据模型决策
分片键决定哪些查询便宜。如果键是 tenant_id，每个租户范围内的查询只访问一个分片，但全局报表必须查询所有分片。如果键是 user_id，用户范围查询是局部的，但租户仪表盘可能分散。应根据主要访问模式选择键，并接受某些查询需要另一种存储。
shard = hash(tenant_id) % shard_count
-- 或使用目录服务映射 tenant_id -> shard哈希路由能分散负载，但跨租户的范围查询代价高。目录路由允许显式放置和更容易的迁移，代价是查找服务和另一个故障域。
哪些事情会变难
跨分片事务需要两阶段提交或 Saga。唯一约束只在本地有效，除非使用全局服务。跨分片连接变成应用侧合并。备份、模式迁移和容量规划都要乘以分片数量。即使哈希均匀，某个租户或某个键占据大部分流量时，分片仍会变热。
再分片
使用取模哈希增加分片会重映射大多数键。一致性哈希或基于目录的拆分移动的数据更少，但仍需要复制行、双写或暂停写入。迁移计划应包含回填、校验期和回滚路径。在生产执行前，先在副本上测试再分片流程。
何时使用
当单库在写吞吐、存储或隔离要求上已无法满足，并且更简单的方案都已用尽时，才使用分片。优点是水平容量；缺点是跨分片操作和运维成为应用责任。与垂直扩容或读副本相比，分片更复杂，应由测量到的极限来证明其必要性。