动态键名导致MongoDB索引失效、查询变慢、聚合更新不可维护、文档膨胀及ESR规则无法应用；应改用数组嵌套对象结构，如{"sensors":[{"id":"device_001","value":23.5}]}。
动态键名会让索引彻底失效
MongoDB 的 B-Tree 索引只支持对固定字段路径建立结构化索引。一旦字段名本身是变量（比如 data.2024_10_01、metrics.cpu_01），你就无法用 createIndex() 指向一个可预测的路径，自然也建不出有效索引。查询时只能全集合扫描，哪怕数据量刚过万，find({ "data.2024_10_01": { $gt: 100 } }) 也会变慢查询。
聚合与更新逻辑变得不可维护
当键名随时间/设备/用户动态生成时，所有业务逻辑都得硬编码拼接字符串——db.t_sensor.updateOne({ _id: id }, { $set: { [`data.${date}`]: value } })。这带来三个实际问题：
- JavaScript 或应用层必须做字符串安全校验，否则注入
data.$where这类非法键会直接报错Invalid field name - 聚合管道里无法用
$objectToArray后再$filter，因为字段名不统一，$unwind后丢失原始上下文 - 备份恢复或跨集群迁移时，WiredTiger 对动态路径的元数据处理更脆弱，曾有案例在 hidden 节点上触发
WT_ROLLBACK错误
文档膨胀与磁盘空间失控
WiredTiger 引擎为每个字段路径单独维护内部 slot 和偏移信息。动态键名导致大量稀疏字段散落在文档中，引擎无法复用已分配的内存块，反而持续追加新 slot。实测中，一个本该 2KB 的传感器文档，因使用 data.device_001、data.device_002… 这类命名，三个月后平均膨胀到 8KB+，且 compact 命令几乎无效——它只回收被删除字段的空间，而动态键名极少被真正删除，只是“不再写入”。
ESR 索引设计规则完全无法应用
ESR（Equality-Sort-Range）是复合索引的黄金顺序，但它的前提是字段路径稳定。如果你把时间戳塞进键名里，就等于把 Range 条件从值层面（{ ts: { $gte: ... } }）强行挪到了路径层面（{"data.20241001": 1}），索引根本没法按时间范围做有序遍历。结果就是：你明明想查“最近7天”，却不得不扫完整个集合，再靠应用层过滤——排序、分页、跳过都得自己实现，还容易漏数据。
真正需要表达多维动态结构时，应该用数组嵌套对象，而不是动态键名。比如把 {"data.device_001": 23.5, "data.device_002": 24.1} 改成 {"sensors": [{ "id": "device_001", "value": 23.5 }, { "id": "device_002", "value": 24.1 }]}。这样既能建 createIndex({ "sensors.id": 1, "sensors.value": 1 })，也能用 $elemMatch 精准查询，还能避免上面所有坑。
