不能只用 _id 做分片键，因其随机性导致写入分散、无法局部聚集，且不支持设备+时间范围的高效查询；应选用 { deviceId: 1, timestamp: -1 } 复合分片键，并注意字段非空、类型正确、预拆分及 $lookup 对齐等约束。
为什么不能只用 _id 做分片键？
物联网写入流量高度集中，设备持续上报数据，_id 默认是 ObjectId（含时间戳），但后 3 字节是随机机器+进程标识，导致新文档写入在多个分片间跳跃，无法局部聚集。更糟的是，查询常按设备 + 时间范围进行，而单靠 _id 无法支撑高效范围扫描——MongoDB 会向所有分片广播查询。
用 { deviceId: 1, timestamp: -1 } 作分片键的实际效果
这是最贴近 IoT 查询模式的复合键：设备 ID 确保同一设备数据落在同一分片（或相邻 chunk），时间戳倒序让最新数据物理连续，利于最近 N 分钟的高频查询。但要注意几个硬约束：
-
deviceId字段必须在所有插入文档中存在且不可空，否则写入失败（shard key 不可 null） -
timestamp必须是 BSONDate类型，不能是字符串或数字，否则范围查询失效、分片不均匀 - 该键无法支持仅按时间范围查询（如“查全网过去一小时所有数据”），这类请求仍需广播到全部分片
- 如果设备 ID 分布严重倾斜（例如某 Top10 设备占 40% 流量），对应 chunk 可能持续分裂不均，需配合
zone手动隔离
如何避免 timestamp 单调递增导致的热点问题？
虽然 timestamp: -1 让新数据追加在 chunk 尾部，但若所有设备在同一秒内集中上报（比如心跳同步触发），就会在单个 chunk 产生写入热点。缓解方式不是换键，而是调整 chunk 行为：
- 建集合时显式设置较小的初始 chunk size：
sh.shardCollection("iot.db", { deviceId: 1, timestamp: -1 }, { chunkSize: 16 })（单位 MB），加快自动分裂响应速度 - 禁用自动平衡器（
sh.setBalancerState(false)）在业务高峰前，手动预拆分（sh.splitAt()）已知热点区间，例如按小时预切{ deviceId: "dev-001", timestamp: ISODate("2025-04-01T00:00:00Z") } - 确保
timestamp是设备本地真实采集时间，而非服务端写入时间——后者会造成大量时间戳相同，加剧热点
聚合查询时 $lookup 和分片键不匹配的坑
当需要关联设备元数据（如设备型号、位置）时，若元数据集合未按 deviceId 分片，或分片键不同，$lookup 会退化为广播式 join，延迟飙升。必须保证：
- 被 lookup 的集合也以
deviceId为分片键（哪怕单字段），且与主表一致 - 聚合管道中
$lookup的localField必须是主表分片键的前缀（这里是deviceId），否则无法下推到分片节点执行 - 避免在
$lookup后再对非分片键字段做$match，这会导致结果拉回 mongos 再过滤，失去分片优势
真正难处理的是跨设备的时间窗口统计（比如“每分钟各区域平均温度”），这种天然需要全局 shuffle，得接受一定延迟，别指望靠分片键优化到底。
