MongoDB事务禁止DDL操作，因元数据变更不可回滚；createIndex在4.4+仅支持普通索引且需集合已存在；跨库DDL仍受限；“建表+写入”需应用层幂等协调。
MongoDB 4.0 事务根本就不存在“之前支持 DDL”的情况——4.0 是首个引入多文档事务的版本，而它从诞生起就明确禁止在事务中执行 createCollection、drop、renameCollection 等 DDL 操作。所谓“4.0 之前”，其实是“根本没有事务”，所以谈不上“支持/不支持 DDL”。
为什么事务内不能执行 createCollection
这不是驱动限制或语法糖缺失，是 MongoDB 服务端硬性拦截：Command not supported inside a transaction。原因很直接：
- 集合创建会修改元数据（如
system.namespaces、WiredTiger 目录结构、文件句柄），这些变更无法安全回滚 - 事务依赖 oplog 实现原子性与可恢复性，而 DDL 变更不在 oplog 的可逆操作集内
- 即使你用
db.runCommand({create: "xxx"})或db.createCollection("xxx")，只要发生在session.startTransaction()之后，立刻报错
实操上必须把建表逻辑剥离到事务外：先用 db.collection.findOne() 或 db.runCommand({listCollections: {filter: {name: "xxx"}}}) 预检，再独立 session 执行建表，并自行处理 NamespaceExists 错误（配合 failIfExists: true）。
createIndex 在 4.4+ 事务中为何有时能用、有时失败
和 createCollection 不同，createIndex 在 MongoDB 4.4+ 开始被有条件允许，但限制极细：
- 仅支持普通索引（非唯一、非 TTL、非文本、非地理空间）
- 集合必须已存在，且不能被其他写操作并发修改（否则 snapshot 冲突）
- 必须显式指定
background: false（默认值），background: true会直接触发CommandNotSupported - 唯一索引校验会在事务 snapshot 下实时检查字段值，哪怕重复值来自未提交的其他事务，也会失败
示例中看似成功，往往是因为你建的是空集合上的普通索引；一旦集合有数据、或字段含重复值、或忘了关 background，就会崩。生产环境强烈建议避开这个坑：索引操作单独跑，低峰期执行，别塞进业务事务里。
跨数据库调用 db.getSiblingDB() 能绕过 DDL 限制吗
不能。事务绑定的是整个 ClientSession，不是某个数据库上下文。哪怕你用 db.getSiblingDB("otherdb").runCommand({create: "xxx"})，只要 session 处于 active transaction 状态，照样报 Command not supported inside a transaction。副本集事务不区分 db，只认 session 生命周期。
最容易被忽略的一点是：很多人以为“事务支持 createIndex 就等于支持 DDL”，其实这只是个特例，且仅限特定版本+特定索引类型。真正的 DDL（建库、建集合、删集合、改结构）至今没被纳入事务能力范围——哪怕到了 6.0，createCollection 依然被拒。设计时得接受这个事实：建模先行，DDL 和业务逻辑必须解耦。
