使用Django bulk_create操作MySQL时触发TransactionManagementError问题求助

针对你遇到的bulk_create时触发TransactionManagementError的问题，结合你的环境（Django2.2.24、MariaDB10.10.2、Cacheops），可以从以下几个方向排查：

1. 检查事务上下文的异常处理 #

• 确认bulk_create_trans方法是否处于@atomic装饰器或atomic()上下文管理器中，查看该方法执行bulk_create之前的代码是否有未捕获的DB操作异常。一旦atomic块内出现未处理的异常，Django会将事务标记为"broken"状态，后续任何DB操作都会抛出这个错误。
• 排查是否存在嵌套的atomic块，Django2.2的嵌套事务如果内层出现异常未处理，会影响外层事务的状态，导致后续操作失败。

2. 验证Cacheops的兼容性问题 #

报错栈中可见Cacheops的钩子参与了DB操作，老版本的Cacheops可能和Django2.2存在事务处理的兼容性问题：

• 临时禁用Cacheops测试：在bulk_create代码块外包裹cacheops.off()上下文，或者临时注释掉settings里的Cacheops配置，重新执行看是否还报错。
• 检查Cacheops版本是否适配Django2.2，尝试升级或降级到对应兼容版本。

3. 排查数据库层的事务配置 #

• 确认MariaDB表的存储引擎为InnoDB，MyISAM不支持事务，会导致事务状态异常。
• 检查数据库连接的事务隔离级别，Django2.2默认使用REPEATABLE READ，确认MariaDB的全局隔离级别和Django配置一致，避免因隔离级别不匹配导致的事务状态错误。

4. 检查批量插入的数据合法性 #

bulk_create的批次插入中如果某一批次存在数据错误，会导致事务进入broken状态，后续批次执行失败：

• 临时将batch_size设为1，执行后查看具体是哪条数据触发了DB错误（比如唯一键冲突、外键不存在、字段类型不匹配等）。
• 验证objs列表中的所有对象字段是否符合模型定义和数据库约束。

5. 排查手动事务操作的干扰 #

检查代码中是否存在手动修改事务状态的逻辑，比如：

• 手动调用transaction.commit()、transaction.rollback()
• 修改transaction.set_autocommit()的状态
  这些操作会破坏Django atomic块的自动事务管理，导致事务状态混乱。

内容的提问来源于stack exchange，提问作者sumit4613