MongoDB事务不支持createCollection和createIndex等DDL操作，仅允许对已存在集合执行CRUD；需在事务外预先创建集合与索引，并通过应用层分阶段+幂等处理保障逻辑原子性。
事务内执行 createCollection 会直接报错
MongoDB 事务不支持集合创建操作。只要在事务中调用 db.createCollection() 或隐式触发建表（比如向不存在的集合写入），就会立即抛出 CommandNotSupported: createCollection is not supported in multi-document transactions 错误。
常见错误场景包括：想在一个事务里“先建表再插数据”，或在迁移脚本中把 DDL 和 DML 混写进同一个 session.withTransaction() 块里。
- DDL 操作（
createCollection、dropCollection、createIndex等）全部被明确排除在事务外 - 事务只允许对**已存在**的集合执行读写（
insertOne、updateMany、find等） - 即使集合在事务前刚被创建，只要事务块里没显式声明它已存在，驱动层也可能因缓存或元数据延迟报错
createIndex 在事务中同样不被允许
和建集合一样，createIndex 是典型的 DDL 操作，MongoDB 明确禁止在事务中调用。试图在 session.withTransaction() 回调里执行 db.users.createIndex({ email: 1 })，会收到 CommandNotSupported: createIndex is not supported in multi-document transactions。
注意：索引创建本身是后台异步操作，但命令提交阶段就被事务管理器拦截，根本不会进入执行队列。
- 索引必须在事务**外**提前建好；否则事务内对字段做查询或排序时可能性能骤降
- 如果业务逻辑依赖新索引（比如唯一约束防重复），得把索引创建和后续业务拆成两个独立步骤，并自行保证顺序和幂等性
- 使用
background: true也不能绕过限制——参数不影响命令是否被允许，只影响建索引时是否阻塞
替代方案：分阶段 + 幂等处理
要实现“原子性建表+写数据”这类需求，只能靠应用层协调。核心思路是把 DDL 和 DML 拆开，用状态标记+重试机制模拟原子性。
典型做法是先在事务外创建集合与索引，再用事务写入数据；但如果失败，需考虑回滚 DDL 的成本太高（比如删集合可能丢数据），所以更稳妥的是：只建索引，集合默认存在，用空集合兜底。
- 启动时或部署脚本中统一执行
db.createCollection("orders")和db.orders.createIndex({ "order_id": 1 }, { unique: true }) - 业务代码只在事务中做
insertOne或updateOne，并捕获duplicate key等错误做重试/提示 - 若真需要动态建集合（如多租户场景），用独立的初始化服务完成，再通知业务服务，不要塞进用户请求的事务链路里
为什么 MongoDB 这么设计？
根本原因是事务的底层实现基于 WiredTiger 引擎的 snapshot isolation，而集合和索引元数据变更涉及全局 catalog 修改，无法被 snapshot 隔离。DDL 会锁库、改结构、触发复制集配置同步，和 ACID 事务的轻量级、短生命周期定位冲突。
这和 PostgreSQL 或 MySQL 的“事务内可建临时表”完全不同——MongoDB 的事务从一开始就没打算覆盖 DDL。
- 4.0 引入事务时就明确划清边界：只支持 CRUD on existing collections
- 哪怕到了 6.0，文档仍强调“DDL commands are never allowed in transactions”
- 别指望未来版本放开——这是架构取舍，不是功能遗漏
createCollection，也不能碰 createIndex，连带所有其他 DDL 命令。这个限制不是临时的，是引擎层硬约束。最容易忽略的是：你以为集合存在，其实它只是“还没被当前 session 刷新元数据”，结果一写就崩。务必在事务前确认集合和索引都已就位。 
