UUID 不适合直接做范围分片键，因其字符串形式按字典序排序会导致前缀重复、数据倾斜和写入热点；改用 hashed 分片需统一格式并避免复合哈希索引，或更优地采用 ObjectId 或 BinData(4) 存储。
UUID 作为分片键直接用于范围分片，会导致严重的数据倾斜和写入热点——因为 MongoDB 默认按字典序对 UUID 字符串排序，而标准 UUID v4 是完全随机生成的，其前缀（如 550e8400）在大量插入时高度重复，造成 chunk 持续分裂失败、迁移卡顿、写入集中在少数分片。
为什么 UUID 不适合直接做范围分片键
UUID 字符串（如 "550e8400-e29b-41d4-a716-446655440000"）本质是 32 位十六进制 + 连字符的文本。MongoDB 对其做范围分片时，会按 UTF-8 字节序比较。结果是：看似“随机”，实则大量 UUID 共享相同前缀（尤其 v4 的时间无关型），导致新文档持续落入同一 chunk，触发频繁 split 和 moveChunk，IO 压力翻倍。
- chunk 分裂失败率升高，
sh.status()中可见大量pending或moving状态 -
db.collection.stats().sharded显示某 shard 的size或count远超其他节点 - 写入吞吐下降，
mongostat中netIn/netOut出现明显单点峰值
用 hashed 索引强制均匀分布，但必须绕过字符串哈希陷阱
MongoDB 对字符串字段建 hashed 索引时，会先将其 UTF-8 编码为字节数组，再哈希。这对 UUID 是可行的，但要注意两点硬限制：
- 不能直接对 UUID 字符串字段创建复合哈希索引（如
{_id: "hashed", ts: 1}），MongoDB 会报错Cannot create a compound index with a hashed index on a non-first field - 如果应用层传入的是带连字符的 UUID 字符串（如
"a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11"），MongoDB 哈希结果稳定；但若混入大小写（"A0EEBC99..."）或空格，则哈希值不同，导致同一条逻辑记录被路由到不同 shard
实操建议：
- 入库前统一转小写并移除连字符：
uuid.replaceAll("-", "").toLowerCase() - 分片命令中明确指定哈希字段为单一字段：
sh.shardCollection("db.col", {"uuid_clean": "hashed"}) - 避免在该字段上建额外的非哈希索引（如
{"uuid_clean": 1}），否则会浪费内存且无实际查询收益
更优解：改用 ObjectId 或二进制存储 UUID
UUID 的根本问题是“作为字符串参与排序和哈希都低效”。生产环境更推荐两种替代路径：
- 不存 UUID 字符串，改用
ObjectId作主键（_id），它天然具备时间戳+机器标识+自增计数，单调递增性可控，配合hashed分片（{_id: "hashed"}）效果极佳 - 若必须保留 UUID 语义，用
BinData(4, "...")存储：将 16 字节原始 UUID 写入BinData类型字段（子类型 4 表示 UUID），再对其建hashed索引。这样跳过字符串编码环节，哈希更稳定，索引体积减少约 30%
示例插入：
db.col.insertOne({
_id: ObjectId(),
uuid_bin: new BinData(4, "oO7JmZyLTOG7bWu8NrgqEQ==")
})
对应分片：
sh.shardCollection("db.col", {"uuid_bin": "hashed"})
哈希分片后，等值查询能走路由，范围查询必须放弃
这是最容易被忽略的代价：一旦用 uuid 字段做了 hashed 分片键，所有形如 db.col.find({uuid: {$gt: "a0ee...", $lt: "b0ee..."}}) 的范围查询，mongos 将无法定位目标 shard，只能广播到全部分片执行——查询延迟陡增，CPU 和网络开销翻倍。
如果你的业务存在以下任一场景，hashed 就不是解法：
- 需要按 UUID 字典序分页（
skip/limit+sort） - 前端传入 UUID 区间做批量拉取（如导出某批次设备数据）
- 依赖 UUID 前缀做业务分组（如
uuid.substring(0,8)表示租户）
此时应放弃 UUID 分片，改用复合键：例如 {tenant_id: 1, uuid: "hashed"}，用 tenant_id 支撑范围查询，用 uuid 的哈希保证单 tenant 内写入均匀。
