MongoDB事务中禁止执行db.createCollection()和createIndex等DDL操作，因oplog无法记录、不可回滚，且会强制终止事务；所有集合必须预先创建，索引须在事务外独立构建并确认就绪后方可执行业务写入。
事务中执行 db.createCollection() 或 createIndex 会直接报错，不是语法或驱动问题，而是 MongoDB 服务端硬性禁止——这是由 oplog 机制和分布式事务一致性要求决定的架构限制，无法绕过。
Command not supported inside a transaction 错误从哪来
这个错误由 mongod 进程在解析命令时立即返回，不进入执行阶段。只要在 session.startTransaction() 之后、commitTransaction() 之前调用任何 DDL 命令（包括 db.runCommand({create: "xxx"})、db.collection.drop()、db.collection.renameCollection()），就会触发该错误。
- 错误信息固定为：
CommandNotSupported: create is not supported in multi-document transactions（或类似变体） - 事务状态会被强制终止：已执行的 CRUD 操作不会自动回滚，除非你手动调用
abortTransaction() - 后续语句不再执行，session 进入不可恢复的 invalid 状态
为什么隐式建集合（如 insertOne）在事务里也失败
平时 db.users.insertOne({}) 能自动创建 users 集合，是因为该行为本质是单文档写入触发的副作用；但在事务中，这个“自动创建”路径被显式拦截——第一次访问不存在的集合时，直接抛 NamespaceNotFound，而不是走建表逻辑。
- 事务内所有集合必须预先存在，且命名合规（不能以
$开头、不能是system.*或temp_*） - 即使你在事务外用
insertOne创建过集合，它可能缺少 validator、collation 或 timeseries 配置，导致事务内写入因 schema 验证失败而中断 - 跨数据库事务允许读写不同库的集合，但所有目标集合仍需在事务前显式创建
createIndex 在事务中为何有时“看似能用”却不可靠
MongoDB 4.4+ 曾短暂允许在事务中对已存在集合创建普通索引（非唯一、非 TTL、非文本），但该行为已在后续版本中统一移除。当前所有稳定版（含 2026 年最新版）均禁止。
-
db.collection.createIndex({x: 1}, {background: true})和{unique: true}都会立刻失败，错误同上 - 即使索引命令没报错（极少数旧版本残留行为），它也是同步阻塞的，会拖长事务生命周期，极易触发
transactionLifetimeLimitSeconds超时 - 后台构建（
background: true）本身依赖异步线程和定时任务，与事务 snapshot 语义冲突，无法保证跨分片一致性
真正安全的替代方案只有两种
DDL 和 DML 必须物理分离，不能靠事务包装“逻辑原子性”。应用层需主动协调时序和幂等性：
- 建集合：用独立 session 执行
db.createCollection("col", {validator: {...}})，捕获NamespaceExists错误实现幂等 - 建索引：单独执行
db.col.createIndex({email: 1}, {background: true})，再轮询db.col.getIndexes()确认状态为"ready"，最后才启动业务事务 - 不要依赖
db.getSiblingDB()切库绕过——事务绑定的是整个 session，不是 db 上下文
最容易被忽略的一点是：**事务外建好集合后，必须确认其元数据已在所有分片/副本集成员上完成同步，否则事务内首次读写仍可能因缓存延迟报错。** 这在 Atlas 多租户或动态 Schema 场景下尤为关键。
