MongoDB事务不支持mongoimport，因其绕过驱动会话机制；仅驱动程序内通过startSession()和insertMany()等操作可纳入事务，且需分批控制超时与文档数。
MongoDB 事务不支持 mongoimport，也不能包裹跨文档的批量导入操作——这是硬性限制，不是配置或写法问题。
为什么不能用事务包装 mongoimport
mongoimport 是独立于 MongoDB Shell 和驱动程序的命令行工具，它直接与 mongod 建立连接并执行写入，完全绕过客户端驱动的会话（session）机制。而 MongoDB 事务必须依托于一个显式开启的会话（startSession()），且所有操作需通过该会话下的 db.collection 方法调用（如 insertMany()、updateOne()）。因此：
-
mongoimport命令本身无法加入事务上下文 - 即使在 shell 中手动开启事务，也无法将
mongoimport的写入纳入其中 - 尝试用
mongosh脚本调用shell.exec()或runCommand({ "eval": ... })同样无效——这些接口不支持事务传播
真正能用事务的导入方式：仅限 PyMongo / Node.js 驱动等客户端代码
只有通过驱动程序发起的、在同一个会话内执行的写操作，才能被事务包裹。典型流程是：
- 用
client.startSession()创建会话 - 在会话中获取数据库和集合句柄（
session.withTransaction(...)） - 用
collection.insertMany()批量插入解析后的 JSON 文档
注意几个关键约束：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 事务有 60 秒默认超时（
maxTimeMS），超时自动中止；大批量导入必须分批，每批控制在几秒内完成 - 单个事务最多写入 1000 个文档（MongoDB 4.2+ 默认限制，可通过
transactionSizeLimitMB调整，但不推荐突破） - JSON 文件若含数组（
[{...}, {...}]），需先用json.load()解析为 Python 列表；若是 JSON Lines（每行一个对象），需逐行json.loads() - 事务内不能执行
createCollection、dropCollection等 DDL 操作（除非使用 4.4+ 的create选项配合insertMany）
常见误操作与后果
以下做法看似“加了事务”，实则完全无效：
- 在 shell 中运行
session.startTransaction()后，再执行mongoimport --file data.json→ 写入不受事务控制，失败也不会回滚 - 用 Python 的
subprocess.run(["mongoimport", ...])包裹在with session.start_transaction():块里 → 子进程无会话上下文，事务对它透明 - 试图在事务中调用
db.runCommand({ "insert": ..., "documents": [...] })导入大量文档 → 单次 insert 命令仍受 16MB BSON 限制，且不支持自动分片键路由，易触发WriteConflict
真正安全的做法是：把 JSON 解析、数据清洗、分批（例如每 500 条一批）、事务写入全部收口在驱动逻辑里，并为每批设置明确的 writeConcern: { w: "majority" }。
导入量大时，事务反而可能是累赘
如果目标只是“确保全量成功或全量失败”，事务并非最优解：
- 事务会显著拖慢吞吐：锁粒度更粗、日志写入更重、内存占用更高
- 36000 个 JSON 文件？更适合用
mongoimport并行 + 外部脚本做状态追踪，而非强行塞进一个事务 - 真正需要事务的场景，通常是“导入 A 文档的同时更新 B 集合的统计字段”，即跨集合强一致性，而非单纯大批量载入
换句话说：事务解决的是业务逻辑一致性，不是导入可靠性。后者靠重试、校验、幂等设计更实际。
