Time Series 集合禁用事务是硬性限制，根本原因在于其桶文档（bucket document）压缩存储模型与ACID强一致性冲突；MongoDB牺牲事务能力以换取写入吞吐、压缩率和时间范围查询性能。
Time Series 集合不支持事务。 这是硬性限制，不是配置问题或版本 bug —— MongoDB 明确禁止在 timeseries 集合上执行任何涉及 session.startTransaction() 的操作，尝试调用会直接报错 CommandNotSupportedOnTimeSeries。
为什么 Time Series 集合禁用事务
根本原因在于底层存储模型：时间序列集合把多个时间点的数据自动压缩打包进“桶文档”（bucket document），写入时由引擎隐式管理结构和边界。事务要求对文档的精确、可回滚的原子修改，而桶的拆分、合并、压缩逻辑与 ACID 的强一致性模型冲突。MongoDB 选择牺牲事务能力，换取写入吞吐、压缩率和时间范围查询性能。
- 事务依赖行级锁或文档级锁，但桶内数据是批量组织的，无法对单个测量值加锁
- 自动按时间分区 + 内置索引优化，让并发写入天然倾向“追加优先”，而非“更新/删除主导”场景
- 绝大多数时序场景（如设备上报、指标采集）本身是只追加（append-only）的，事务需求极低
遇到“必须保证一致性”的混合操作怎么办
当业务逻辑既需要写入时序数据，又需要同步更新元数据（如设备状态、告警计数器、用户配置），不能靠单个事务兜底，得拆开处理：
- 先写入普通集合（如
devices或alerts），用事务保证元数据一致性 - 再写入
timeseries集合（如sensor_readings），不参与事务，但带上相同metafield值（如"deviceId": "dev-123"）便于后续关联 - 如果写入时序失败，靠应用层重试 + 幂等设计（例如用
timestamp+deviceId做唯一索引约束）防止重复 - 避免在事务中读取刚写入的时序数据 —— 它不在事务快照里，读到的是最终一致结果
替代方案：用普通集合模拟时序行为（仅限小规模或强事务需求）
若业务真有高频更新、删除、跨时间点事务联动（比如修正某分钟所有传感器误差），就别硬套 timeseries 集合：
- 用普通集合 + 手动桶模式（
bucket文档含start/end时间、数组存测量值） - 为
bucket文档加唯一复合索引：{"deviceId": 1, "start": 1}，配合findAndModify或事务做原子更新 - 注意：这会损失原生时序集合的自动压缩、窗口函数支持、
$dateTrunc优化等特性 - 查询性能下降明显 —— 尤其是跨桶时间范围扫描时，需手动
$unwind数组，CPU 和内存开销大
真正需要事务 + 时间维度的场景，往往暴露了数据建模偏差：时序数据本身不该承载状态变更逻辑。把“设备是否在线”这类状态存在 devices 集合里，把“温度读数”存在 readings（timeseries）里，靠 metafield 关联，才是 MongoDB 5.0+ 推荐的解耦方式。强行塞进一个事务，反而让系统更难维护。
