事务执行中途断连且autocommit=false时，数据状态不可控：innodb不自动回滚未提交事务，仅保证已提交事务持久性；连接中断导致事务悬挂，可能部分写入或等待指令，重试易引发重复执行或误判回滚，必须结合show engine innodb status人工验证并辅以幂等设计与连接池健康检测。
事务执行中途断连，autocommit=False 时数据状态不可控
连接在 COMMIT 前中断，InnoDB 不会自动回滚已执行但未提交的语句——它只保证已提交事务的持久性，不保证“未提交事务一定被清理”。你看到的 OperationalError: (2013, 'Lost connection to MySQL server during query') 发生在事务中间，此时事务处于“悬挂”状态：服务器端可能已部分写入、也可能正在等待客户端指令，但客户端完全失去上下文。
常见错误现象包括：应用层捕获异常后直接重连并重试，结果导致同一笔业务被重复执行（如转账扣款两次）；或误以为事务已回滚，实际数据已被部分落盘。
- 不要依赖
auto_reconnect=True在事务中自动恢复——它只在语句执行前 ping 连接，无法感知事务上下文 - 避免在事务内做耗时操作（如 HTTP 调用、文件读写），否则超时风险陡增
- 务必在
try块外显式关闭连接，否则连接池可能复用一个半死连接
SHOW ENGINE INNODB STATUS 是唯一能确认事务真实状态的手段
当怀疑事务是否已部分提交，不能靠日志或应用层判断。MySQL 重启后，InnoDB 会根据 redo log 和 undo log 自动恢复或回滚，但运行中必须人工介入验证。
执行 SHOW ENGINE INNODB STATUS\G 后重点看 TRANSACTIONS 部分：
- 查找
ACTIVE状态且mysql tables in use> 0 的事务，确认其TRX_ID和TRX_STATE - 若显示
TRX_STATE: RUNNING或LOCK WAIT，说明事务仍在服务端挂起，需人工KILL对应线程 - 若已消失，不代表已提交——可能是被
wait_timeout强制中断后由 InnoDB 清理了，但清理前是否写盘需结合redo log刷盘位置判断
重试逻辑必须带幂等标识和事务边界重置
事务中断后重试不是简单“再连一次再跑一遍 SQL”，而是要重建完整事务语义。最稳妥的做法是：把业务操作封装成幂等单元，并在每次重试前确保旧连接彻底释放、新连接开启全新事务。
- 在 SQL 层加唯一约束（如
INSERT ... ON DUPLICATE KEY UPDATE）或应用层生成业务 ID 做去重校验 - 重试前调用
connection.close()，不要依赖连接池自动回收——有些池子（如 SQLAlchemy 的NullPool）会缓存失效连接 - 重连后必须显式调用
connection.begin()或start_transaction()，不能复用上一个连接对象的事务状态 - 指数退避只适用于非事务场景；事务重试建议固定间隔（如 1s）+ 最多 2 次，超过即告失败并交由人工核查
根本解法：调高 wait_timeout 并配 ping=1 健康检查
90% 的“事务中途断连”其实源于 wait_timeout 设置过低（比如云厂商默认设为 300 秒），而连接池没做空闲检测。事务还没执行完，MySQL 已静默 kill 掉连接。
- 在
my.cnf中设wait_timeout = 3600，并重启 MySQL（SET GLOBAL临时生效但不持久） - 连接池初始化时启用
ping=1（PyMySQL）或testOnBorrow=true（HikariCP），确保每次取连接都执行PING检测 - 连接池的
maxLifetime必须小于wait_timeout（建议设为wait_timeout * 0.8），避免连接在 MySQL 杀掉前就被池子主动淘汰
事务中断不是靠重试兜底的问题，而是连接生命周期管理失配的信号。一旦出现，优先查 wait_timeout 和连接池空闲配置，而不是堆重试代码。
