分片键必须匹配查询模式，如高频查 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，数据就找不到了。
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。
核心原则是：路由函数必须是纯函数——输入相同，输出必相同；且所有服务（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 和数据量标准差。差三倍以上，就得回头调分片策略。
