mybatis批处理未提交导致事务锁住，本质是autocommit=0下开启显式事务后未调用commit()，使连接长期占用锁资源；需通过innodb_trx和processlist联合定位并kill thread_id释放。
MyBatis 批处理未提交导致事务锁住，本质是 autocommit=0 下的显式事务没收口——不是批处理本身有问题，而是你开了事务却忘了 commit。
查 INNODB_TRX 时别只盯 TRX_QUERY 是否为空
MyBatis 的 batch 模式（如 SqlSessionExecutor + ExecutorType.BATCH）在 autocommit=false 时会复用同一个事务上下文。一旦调用 sqlSession.insert("xxx", list) 后没调 sqlSession.commit()，整个连接就卡在 RUNNING 状态，TRX_QUERY 往往为空或只剩一条 INSERT ... VALUES (...),(...) ——这不代表它“执行完了”，只说明语句发出去了，事务还悬着。
- 执行
SELECT TRX_ID, TRX_STATE, TRX_STARTED, TRX_MYSQL_THREAD_ID, TRX_QUERY FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 30 - 重点看
TRX_STARTED时间戳：早于当前时间 30 秒以上，基本就是 MyBatis 批处理后漏commit()的线程 -
TRX_QUERY为空？别放松——MyBatis BATCH 模式下，批量语句可能已刷入 InnoDB，但事务边界仍在应用层控制
关联 PROCESSLIST 时注意 User 和 Host 字段暴露的客户端特征
MyBatis 应用通常用固定账号连接（如 app_user），HOST 字段常带端口号（如 10.20.30.40:56789），可快速定位到具体 Pod 或机器。但要注意：COMMAND 显示为 Sleep、TIME 很大（比如 1200 秒）、STATE 为空，这种组合大概率就是 MyBatis 批处理提交失败后“静默挂起”的连接。
- 执行
SELECT ID, USER, HOST, COMMAND, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID IN (SELECT TRX_MYSQL_THREAD_ID FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'RUNNING' AND TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 30) - 如果
USER是system user，别碰——那是主从同步线程，和 MyBatis 无关 - 若
INFO显示类似INSERT INTO t_user (...) VALUES (...)，且TIME持续增长，说明该连接可能卡在应用层网络调用（如 HTTP 超时未返回）或异常未捕获，导致 commit 没走到
别用 KILL QUERY，必须用 KILL thread_id
对 MyBatis 批处理挂起的连接执行 KILL QUERY <code>thread_id 只会中断当前语句，事务仍活跃，MDL 锁和行锁全在；只有 KILL <code>thread_id 才能触发回滚、释放所有锁。但得先确认这个 thread_id 真属于可杀范围：
- 检查对应服务是否在滚动发布中——刚上线的新实例可能有残留连接
- 确认该连接上没有正在跑关键定时任务（比如
INFO里含UPDATE job_status SET running=1） - Spring 项目中，若用了
@Transactional包裹批处理方法，但方法内调了外部 RPC 且没设超时，KILL后重试仍会复现；此时必须改代码，加try/catch并确保rollback或用@Transactional(timeout = 30)
MyBatis 配置里藏着两个关键开关
很多问题其实在配置阶段就能堵住：defaultExecutorType 和 autoCommit 设置不匹配，是批量场景下事务失控的常见源头。
- MyBatis 默认
defaultExecutorType=SIMPLE，但显式设为BATCH时，必须配合手动 commit；若同时设了spring.datasource.hikari.auto-commit=true，则 Hikari 会忽略 MyBatis 的 batch 模式，走自动提交——这时反而不会锁住，但失去了批量性能 - 更危险的是：Spring Boot 2.3+ 默认
spring.datasource.hikari.auto-commit为true，但开发者在代码里又手动调sqlSession.commit()，结果抛出Cannot commit when auto-commit is enabled异常，而这个异常被吞掉，连接就滞留在事务中 - 建议统一策略：批量操作一律用
ExecutorType.BATCH+auto-commit=false，并在 finally 块或 try-with-resources 中确保commit()或rollback()执行
真正难排查的从来不是“有没有长事务”，而是“为什么这个事务没提交”——MyBatis 批处理里一次 commit() 调用失败，可能因为网络抖动、日志框架阻塞、甚至 JVM Full GC 导致线程停顿超过超时阈值，这些都不会在 INNODB_TRX 里留下痕迹，只能靠应用侧埋点或连接池 active connection 监控反推。
