事务“自己提交”实为隐式提交导致锁提前释放，常见于ddl、lock tables、set autocommit=1等语句；需通过innodb_trx、show engine status及应用日志交叉验证，并严格隔离ddl与业务事务。
为什么事务突然“自己提交”了，锁却没按预期释放
MySQL事务在未显式调用 COMMIT 或 ROLLBACK 的情况下提前结束，本质是触发了隐式提交（implicit commit），导致事务上下文被销毁、持有的行锁/表锁立即释放——但应用层还误以为事务仍在运行，后续操作（如再次 COMMIT）会报错或逻辑错乱。这不是锁没释放，而是**锁被提前释放了**，且不报错、无日志提示，极难察觉。
哪些语句会偷偷提交当前事务
以下语句执行时，MySQL 会强制提交当前事务（无论是否在 BEGIN 块内），然后开启新事务执行自身：
-
CREATE TABLE、DROP TABLE、ALTER TABLE、TRUNCATE TABLE -
LOCK TABLES（即使只读锁）、UNLOCK TABLES -
SET AUTOCOMMIT = 1（注意：设为 0 不会提交，但设为 1 会） -
RENAME TABLE、ANALYZE TABLE、OPTIMIZE TABLE
常见踩坑场景：
- 在事务中执行
ALTER TABLE t_log ADD COLUMN ts TIMESTAMP→ 前面所有 INSERT 全部落地，无法回滚 - 用
LOCK TABLES orders READ做简单校验 → 当前事务瞬间提交，后续 UPDATE 失去原子性保障 - ORM 框架自动执行
SET AUTOCOMMIT = 1清理连接状态 → 正在跑的业务事务被静默终结
如何确认问题出在隐式提交
关键看三处是否一致指向“事务中途消失”：
- 应用日志显示事务开始后某条 SQL 执行成功，但后续
COMMIT报ERROR 1370 (42000): execute command denied—— 这不是权限问题，是事务已不存在 -
SELECT * FROM information_schema.INNODB_TRX查不到该事务 ID，但应用代码明确处于begin到commit区间 -
SHOW ENGINE INNODB STATUS\G的TRANSACTIONS段里，对应时间点没有该事务，或只看到它“刚启动就结束了”（TRX_STARTED和TRX_END_TIME几乎相同）
若满足以上任意两点，基本可断定是隐式提交干扰。此时再检查应用代码或中间件日志中，是否在事务块内混入了上述 DDL 或锁表语句。
避免隐式提交导致锁异常的实操要点
隐式提交不可禁用，只能规避。核心原则是：**DDL 和锁操作必须与业务事务物理隔离**。
- 禁止在业务事务块（
BEGIN…COMMIT）内执行任何 DDL；DDL 单独走独立连接或连接池空闲连接 - 用
SELECT ... FOR UPDATE替代LOCK TABLES实现行级控制，避免表级锁 + 隐式提交双重风险 - 连接池配置中关闭自动
SET AUTOCOMMIT = 1行为（如 HikariCP 的connection-init-sql不设该语句） - 在事务模板（如 Spring
@Transactional）上加 AOP 日志，记录进入/退出时的SELECT @@autocommit和SELECT TRX_ID FROM information_schema.INNODB_TRX，快速定位中断点
最隐蔽的坑在于：某些数据库代理（如 ProxySQL、ShardingSphere）会在后台悄悄执行 SHOW VARIABLES 或心跳语句，若这些语句被误判为“需隐式提交”，也可能污染事务状态——务必查清代理行为日志。
