元数据必须收敛到metaField且建表时冻结结构，因时间序列集合底层采用列式存储，新增metaField字段会导致其退化为嵌套BSON，破坏压缩与索引优化。
直接结论：元数据必须收敛到 metaField，且字段结构需在建表时冻结；不能靠后期加字段补救，否则会破坏时间序列集合的列式压缩和索引优化能力。
为什么 metaField 不能动态扩展
时间序列集合在底层使用列式存储，metaField 中每个键（如 sensorId、location.city）都会被单独提取为列并建立字典编码。一旦集合创建完成，MongoDB 就固化了这些列的 schema —— 后续插入文档若新增 metaField 下的字段（比如突然加个 firmwareVersion），该字段不会进入列式索引，也不会参与压缩，只会退化为嵌套 BSON 存储，导致：
- 磁盘空间浪费（列式压缩失效）
- 按新字段查询变慢（无法走
metaField复合索引） - 聚合时
$group或$facet对该字段的统计效率骤降
metaField 建模的实操约束
建模不是“尽量多塞”，而是“只放高频过滤+低基数+稳定不变”的标识字段。参考 OPPO WatchS 的落地实践：
- 必须包含设备唯一标识：如
deviceId（字符串，不可为空） - 允许嵌套但层级 ≤2：如
location: { city: "Shenzhen", zone: "A3" }可行；location: { site: { building: { floor: "B2" } } }不推荐（解析开销大、索引膨胀） - 禁止放入时间相关值：如
lastHeartbeat、onlineStatus—— 这些属于指标（value），不是元数据（source） - 避免高基数字符串：如
ipAddress或完整userAgent，会显著拉低字典压缩率；可哈希后存ipHash
如何验证 metaField 是否建模合理
建完集合后，立刻用以下命令检查实际生成的列式元数据结构：
db.runCommand({
listCollections: 1,
filter: { name: "your_timeseries_collection" }
})
重点看返回中的 options.timeSeries.metaField 是否与你设计一致；再查索引：
db.your_timeseries_collection.getIndexes()
确认存在形如 { "time": 1, "metaField.sensorId": 1, "metaField.location.city": 1 } 的复合索引 —— 如果没有，说明 metaField 字段未被识别，大概率是建表时拼写错误或用了点号（.）以外的分隔符。
容易被忽略的兼容性陷阱
MongoDB 7.0 要求 metaField 必须是顶层字段名，且不能与指标字段同名。例如下面这个文档会报错：
{
"timestamp": ISODate("2026-09-07T12:00:00Z"),
"metaField": { "deviceId": "watch-001" },
"deviceId": "watch-001", // ❌ 冲突！指标字段不能重名
"temperature": 36.5
}
另外，如果你从 MongoDB 6.x 升级上来，旧版允许 metaField 为任意字段名（比如叫 tags），7.0 会拒绝读取 —— 升级前必须用 mongodump + 修改文档结构 + mongorestore 迁移，不能原地升级。
