Time Series 集合禁用事务是硬性限制，根本原因在于其桶文档压缩存储模型与ACID强一致性冲突；MongoDB牺牲事务能力以换取写入吞吐、压缩率和时间范围查询性能。
不支持，且是硬性限制，不是配置或版本问题。 尝试在 timeseries 集合上执行任何事务操作（如 session.startTransaction()），会直接报错 CommandNotSupportedOnTimeSeries。
为什么 timeseries 集合禁用事务
根本原因在底层存储模型：MongoDB 把多条时间点数据自动压缩进“桶文档”（bucket document），由引擎隐式管理拆分、合并与边界。而事务要求对单个文档的精确、可回滚修改——桶内数据是批量组织的，无法对某一条测量值加锁或回滚；事务依赖的文档级锁机制与这种压缩结构天然冲突。
- 桶文档没有固定 schema，写入时字段动态聚合，事务快照无法稳定捕获“单条记录”的状态
- 自动按时间分区 + 内置索引优化，使并发写入天然倾向追加（append-only），而非更新/删除主导场景
- 绝大多数时序场景（如设备上报、指标采集）本身不要求跨时间点的强一致性，事务需求极低
遇到混合操作（时序 + 元数据）怎么办
当业务逻辑既要写入时序数据，又要同步更新设备状态、告警计数器等元数据，不能靠单个事务兜底，必须拆开处理：
- 先用事务写入普通集合（如
devices或alerts），保证元数据一致性 - 再单独写入
timeseries集合（如sensor_readings），带上相同metaField（例如"deviceId": "dev-123"）便于后续关联 - 若时序写入失败，靠应用层重试 + 幂等设计兜底：例如在
sensor_readings上建唯一索引{"deviceId": 1, "timestamp": 1} - 避免在事务中读取刚写入的时序数据——它不在事务快照里，读到的是最终一致结果
强行需要事务的替代方案
如果业务真有高频更新、删除、跨时间点修正等强事务需求（比如批量修正某分钟所有传感器误差），就别用原生 timeseries 集合：
- 改用普通集合 + 手动桶模式：每个文档代表一个时间窗口（含
start/end字段 + 测量值数组） - 为该集合加唯一复合索引
{"deviceId": 1, "start": 1}，配合findAndModify或事务做原子更新 - 注意：这会丢失原生
timeseries的自动压缩、$dateTrunc优化、窗口函数等能力，性能和查询便利性需自行权衡
真正容易被忽略的是：事务失败后，应用层重试逻辑是否覆盖了时序写入的幂等性验证——漏掉这点，重复写入可能污染数据，而 MongoDB 不会在服务端帮你拦截。
