分片键必须匹配查询模式，如高频查 user_id 则用其哈希，查时间范围则按月分片；避免低频高基数字段或未标准化数据；Redis Cluster 基于 key 哈希槽路由，MongoDB 依赖分片键前缀路由；手动分片需确保路由函数纯且统一；JOIN 和全局排序需应用层处理或引入专用引擎。
分片键选不对，再好的分片策略也白搭
分片不是简单按 id % N 一砍了事。真实场景中，热点集中在某个时间范围或用户区域，如果用自增 id 作分片键，新数据全打到最新分片，其他分片吃闲饭，负载严重不均。
真正该看的是查询模式：90% 请求带 user_id？那就用它哈希分片；查得最多的是 created_at 范围？考虑按时间范围分片（如 202401、202402）；混合场景可组合，比如 shard_key = user_id + '_' + substr(created_at, 0, 7)。
- 避免用高基数但低查询频率的字段（如
uuid），哈希后分布虽均匀，但无法利用索引加速单条查询 - 禁止用浮点数或含特殊字符的字符串直接哈希，先做标准化处理，否则同一逻辑值可能被散到不同分片
- 分片键一旦选定，后续改成本极高——多数系统不支持在线重分片，得停服迁移
Redis Cluster 和 MongoDB Sharding 的分片逻辑差异
Redis Cluster 固定 16384 个哈希槽（hash slot），客户端计算 CRC16(key) % 16384 得到槽位，再查本地槽路由表发往对应节点。它不关心业务语义，只认 key 字符串本身。
MongoDB Sharding 则依赖分片键建立索引，路由服务（mongos）解析查询条件，判断能否命中分片键前缀。比如分片键是 {region: 1, user_id: 1}，查 {region: "cn"} 能路由到部分分片，但查 {user_id: 123} 就得广播到所有分片。
- Redis 里
keys *、scan这类无 key 精确匹配的操作，在集群模式下直接报错或只作用于本地节点 - MongoDB 中，缺失分片键的写操作会被拒绝；聚合管道若没加
$match在分片键上，性能会断崖下跌 - 两者都不支持跨分片的事务一致性——Redis Cluster 没有跨槽事务，MongoDB 的分布式事务默认关闭且代价高
手动分片时，路由逻辑必须和写入逻辑强一致
自己用代码实现分片（比如把订单存到 orders_001 ~ orders_128 表），最容易出问题的是「读写不一致」：写的时候按 user_id % 128 存到 orders_042，读的时候却用了 order_id % 128 去查 orders_087，数据就找不到了。
核心原则是：路由函数必须是纯函数——输入相同，输出必相同；且所有服务（API、定时任务、后台管理）调用同一份路由逻辑代码，不能各写各的。
- 把分片计算封装成独立函数，例如
get_shard_table(user_id, total_shards=128)，严禁在 SQL 拼接里重复写%表达式 - 测试阶段必须覆盖边界值：
user_id = 0、负数（某些语言取模结果不同）、超大整数（溢出导致符号翻转） - 上线前用影子流量比对：新老路由同时计算，日志记录不一致 case，不修复完不能切流
分片后 JOIN 和全局排序变成硬伤
原本一条 SELECT * FROM orders JOIN users ON orders.user_id = users.id，分片后 orders 和 users 可能不在同一库，数据库层无法完成 JOIN。你得在应用层拆解：先查出一批 user_id，再用 IN 批量拉用户数据，自己合并。
同理，要取“最近 100 笔订单”，分片后每个库只能返回自己的 Top 100，应用层得做归并排序，内存和网络开销陡增。
- 优先用冗余字段规避 JOIN：比如订单表里冗余
user_name、user_region，查得快，更新时用异步消息补全 - 全局排序需求强烈的话，别硬扛——引入
Elasticsearch或ClickHouse做汇总索引，写时双写，读时查专用引擎 - 分页慎用
OFFSET：跨分片取第 10000 条，意味着每个分片都得算出前 10000 条再归并，响应时间不可控；改用游标分页（WHERE created_at ）更靠谱
分片从来不是“加个配置就变快”的银弹。最常被跳过的一步，是提前压测分片键倾斜度——用真实流量采样跑 5 分钟，看各分片的 QPS 和数据量标准差。差三倍以上，就得回头调分片策略。
