MongoDB分片集群通过zone标签机制实现冷热分离：先为SSD/HDD分片添加标签，再用updateZoneKeyRange绑定时间范围，配合手动moveChunk迁移存量数据，而非依赖存储引擎自动识别磁盘类型。
MongoDB分片集群本身不提供“分层存储”原生能力，但可以通过 zone + zone tag 机制，结合 shard 的物理部署位置（如 SSD/HDD 服务器），实现逻辑上的冷热数据分层路由——关键在于你能否把硬件差异映射为可被 MongoDB 路由策略识别的标签。
为什么不能直接用 storage engine 配置区分 SSD/HDD
MongoDB 的 wiredTiger 存储引擎允许为单个实例配置 directoryForIndexes 或使用不同挂载点，但它不感知底层磁盘类型，也不支持跨 shard 统一调度 I/O 类型。也就是说：wiredTiger 不知道某台 mongod 是跑在 SSD 还是 HDD 上，更不会自动把“热数据”写到 SSD shard、“冷数据”写到 HDD shard。
真正起作用的是分片层级的 zone 标签和 shard key 范围绑定——这是唯一能强制数据落盘到指定物理介质的可控路径。
如何给 SSD/HDD shard 打上 zone 标签
假设你已部署好两个 shard：一个运行在 NVMe 服务器（shard01），一个运行在 SATA HDD 服务器（shard02）。你需要做三件事：
- 为每个 shard 添加 zone 标签：
sh.addShardTag("shard01", "SSD")<br>sh.addShardTag("shard02", "HDD") - 为集合启用分片，并选择一个支持范围划分的
shard key（如{created_at: 1}或{event_type: 1, created_at: 1}） - 用
sh.updateZoneKeyRange()显式划定数据范围归属：sh.updateZoneKeyRange("db.collection", {created_at: MinKey}, {created_at: ISODate("2025-01-01")}, "HDD")<br>sh.updateZoneKeyRange("db.collection", {created_at: ISODate("2025-01-01")}, {created_at: MaxKey}, "SSD")
注意：updateZoneKeyRange 的键范围必须与 shard key 结构完全一致，且不能重叠；MinKey/MaxKey 是边界占位符，不是字符串。
zone 分层的实际限制与坑点
这种方案看着清晰，但落地时容易踩几个硬伤：
-
zone是静态绑定，无法自动感知数据访问热度——你得自己判断哪些时间范围/业务类型该归 SSD，然后手动调整keyRange，没有自动冷热识别 - 一旦数据写入某 shard，就不会因 zone 变更而自动迁移；迁移必须靠
moveChunk或等待 balancer 触发，且 balancer 默认忽略 zone 约束（需显式开启sh.enableSharding("db")后再设 zone） - 如果
shard key选择不合理（比如用了低基数字段{status: 1}），会导致 chunk 无法切分，整个 zone 策略失效 - 所有 mongos 实例必须能连通 config server 并加载最新 zone 配置，否则路由可能绕过 zone 约束
SSD/HDD 混合部署下必须检查的配置项
光打标签不够，下面这些配置漏掉任何一个，zone 就形同虚设：
- 确认
mongos进程启动时未加--noAutoSplit（否则 chunk 不分裂，range 无法生效） - 检查 balancer 是否开启：
sh.getBalancerState()返回true；若关闭，需手动sh.startBalancer() - 确保 config server 副本集状态正常：
rs.status()中所有节点stateStr为PRIMARY或SECONDARY，无STARTUP2卡住 - 验证 shard 的
tags已写入 config 数据库：db.shards.find({ _id: "shard01" })应含"tags" : ["SSD"]
最常被忽略的是：zone 策略只对新写入或迁移后的 chunk 生效，已有数据不会自动重分布——上线前务必用 sh.status() 看清当前 chunk 分布，必要时先 moveChunk 清场。
