LOCK TABLES一定会隐式提交当前事务，因为其非事务安全的设计要求MySQL在执行前强制清空事务上下文以切换至全局表锁状态，同时释放所有InnoDB行锁、间隙锁和临键锁。
LOCK TABLES 为什么一定会隐式提交当前事务
因为 LOCK TABLES 不是事务安全的操作，MySQL 在执行它之前会强制提交当前事务——这不是 bug，是设计如此。InnoDB 的事务锁（如行锁）和 LOCK TABLES 的表级锁由两套机制管理，无法共存。一旦你调用 LOCK TABLES，MySQL 必须先清空事务上下文，才能安全地切换到全局表锁状态。
常见错误现象：
- 手动
BEGIN→ 插入数据 →LOCK TABLES t1 WRITE→ROLLBACK，结果插入的数据仍在 - 在 Navicat 或 DBeaver 中勾选“自动提交”，又执行了
LOCK TABLES，之后所有 DML 都变成自动提交，事务控制完全失效
关键点：
-
LOCK TABLES触发隐式提交，与当前autocommit设置无关；即使SET autocommit = 0，它照样提交 - 它不仅提交事务，还会释放当前会话持有的所有 InnoDB 行锁、间隙锁、临键锁
-
UNLOCK TABLES本身也会触发一次隐式提交（前提是此前执行过LOCK TABLES）
哪些 LOCK TABLES 场景最容易踩坑
多数人以为只在显式写 LOCK TABLES 时才触发，其实很多间接路径也绕不开：
- 使用
FLUSH TABLES WITH READ LOCK后再执行START TRANSACTION：FLUSH不提交，但后续START TRANSACTION会先提交前一个事务（如果存在） - 在存储过程中调用
LOCK TABLES，哪怕外面已BEGIN，过程内一锁就破事务 - ORM 框架底层执行迁移或备份逻辑时动态拼接
LOCK TABLES（比如某些 Django 备份插件），你根本看不到 SQL，但事务早已被切开 -
LOCK TABLES t1 READ, t2 WRITE这种多表混合锁，只要任一表触发锁获取，整个事务就被提交
如何验证 LOCK TABLES 是否已破坏事务
不能靠“我还没 COMMIT”来判断事务是否还在。运行时必须查状态：
- 执行
SELECT @@in_transaction：值为0就说明事务已不在 - 更准的是查
SELECT TRX_ID, TRX_STATE FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID = CONNECTION_ID()，返回空行或TRX_STATE != 'RUNNING'即已退出事务 - 应用层（如 Python + PyMySQL）要同时检查
conn.get_autocommit()和conn.in_transaction，单看一个容易误判——比如get_autocommit()是False，但in_transaction已是False，说明事务已被LOCK TABLES强制终结
替代 LOCK TABLES 的安全方案
除非你在做物理备份或极低流量时段的结构变更，否则应避免 LOCK TABLES。真正需要并发安全时，优先走 InnoDB 原生机制：
- 读一致性需求：用
START TRANSACTION WITH CONSISTENT SNAPSHOT+ 普通SELECT，不加任何锁 - 写冲突控制：用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE，它们属于事务内行锁，可回滚、可嵌套、不触发隐式提交 - DDL 安全变更：用
pt-online-schema-change或gh-ost，它们内部用触发器+影子表，全程不锁主表 - 真要锁表导数据：改用
FLUSH TABLES WITH READ LOCK+mysqldump+UNLOCK TABLES，这个组合虽也锁库，但至少不混进业务事务流
最常被忽略的一点是：LOCK TABLES 和事务不是“不兼容”，而是“互斥”——它根本不在事务模型里。你试图把它塞进事务，就像往 JSON 字符串里硬插一段 HTML 标签，解析器第一反应永远是报错或截断。
