数据库分片

分片键的选择

分片键（Shard Key）决定了每行数据被路由到哪个节点，是分片设计最关键的决策。理想的分片键需要做到：数据分布均匀（避免热点）、查询时能直接定位到单个分片（避免跨分片 scatter-gather）。

常见的选择是用户 ID——既保证单个用户的数据聚集在一个分片上，又能通过简单取模路由。但时间戳就是糟糕的分片键：新数据总是写到时间最新的分片，造成严重的写热点，其他分片几乎闲置。[1]

分片的代价

分片显著增加了系统复杂度。跨分片的 JOIN 无法在数据库层面完成，只能在应用层做内存合并；全局唯一 ID 需要分布式 ID 生成器；分布式事务变得极其复杂；甚至连 COUNT(*) 都需要汇总所有分片的结果。

正因如此，分片是最后的手段，在单机读写分离、缓存、索引优化都无法满足需求之前，不应该引入分片。阿里巴巴开源的 ShardingSphere（前身是 Sharding-JDBC，2016 年开源）是目前 Java 生态最成熟的分片中间件；MongoDB 原生支持自动分片（Auto-Sharding），是少数在数据库层面内置这个能力的系统。