事务中混用未分片与分片集合会报错，因未分片集合固定在主分片而分片集合按键路由至不同分片，mongos无法保证跨分片原子性，触发cross-shard transaction not allowed错误。
事务中混用未分片集合和分片集合会报错
直接原因：MongoDB 事务在分片集群中要求所有参与写入的集合必须路由到同一分片，而未分片集合（unsharded collection）固定位于主分片（primary shard），分片集合（sharded collection）则按分片键分散在多个分片上。当事务同时操作二者时，mongos 无法保证原子性写入——因为未分片集合只能写入主分片，而分片集合的写入目标由分片键决定，可能落在其他分片，触发 cross-shard transaction not allowed 错误。
为什么“同属一个数据库”也不行
即使两个集合都在 ecommerce 数据库下，只要一个是未分片、一个是已分片，事务仍会失败。关键不在于数据库归属，而在于物理路由路径是否唯一：
- 未分片集合的所有读写请求都由 mongos 路由到该数据库的主分片（
sh.getShardDistribution()可查） - 分片集合的读写请求按分片键哈希或范围路由，可能命中任意分片
- 事务 session 只能绑定一个分片上下文，无法跨分片协调 writeConcern 或 oplog 时间戳
典型错误信息：Transaction numbers are only allowed on a replica set member or a sharded cluster（表面看是部署问题，实则是路由冲突）。
如何验证集合是否“真正兼容”事务
别只看 db.collection.stats() 的 sharded 字段，还要确认它们是否实际落在同一分片：
- 对未分片集合执行
db.runCommand({getShardVersion: "coll_name"})，检查返回的shard字段 - 对分片集合执行
sh.status()，确认其 chunk 分布；再用sh.findChunkFor( {查某个样例文档路由到哪个分片: } ) - 两者
shard名称必须完全一致，否则事务启动即失败
注意：即使你用 sh.addShardToZone() 把分片集合“限定”到某分片，只要它仍是分片集合，其 chunk 就可能被 balancer 迁移走——未分片集合却永远钉死在主分片，这种动态 vs 静态的不匹配是根本矛盾。
替代方案不是“绕过限制”，而是重构数据布局
强行用 $lookup 或应用层 join 模拟事务语义，只会放大一致性风险。可行路径只有两条：
- 把未分片集合也分片（需满足：有合适分片键、数据量足够大、能接受迁移停机）
- 把分片集合降级为未分片集合（仅限测试或小规模场景，用
sh.disableSharding("db.coll")，但会丢失水平扩展能力）
最容易被忽略的一点：分片集群里“主分片”本身也是副本集，但它不参与跨分片事务协调——它的角色只是未分片集合的默认落点，而非事务仲裁节点。这点在排查 writeConcernMajorityJournalDefault: false 报错时尤其关键。
