MySQL中LOCK TABLES搭配autocommit与START TRANSACTION的疑问

嘿，这个问题确实容易绕晕——毕竟START TRANSACTION看起来就是专门用来开事务的，为啥官方偏要让用SET autocommit=0呢？核心原因在于LOCK TABLES和事务的交互逻辑有坑，我给你拆解清楚：

1. START TRANSACTION会触发隐式提交，破坏事务连续性 #

当你执行START TRANSACTION之后再跑LOCK TABLES，MySQL会偷偷做一件事：先隐式提交当前已经开启的事务，再执行锁表操作。这就意味着，你原本想把「锁表+后续业务操作」放在同一个事务里，但START TRANSACTION + LOCK TABLES的组合会直接把事务劈成两半——锁表操作本身就把前面的事务给提交了，后续的DML操作其实是在一个新的、无关联的事务里。

举个错误示例就能看明白：

START TRANSACTION;
LOCK TABLES my_table WRITE; -- 这里MySQL会隐式提交上面的START TRANSACTION事务
INSERT INTO my_table VALUES (1);
COMMIT; -- 只提交了INSERT，锁表操作早已经脱离事务了
UNLOCK TABLES;

这种情况下，如果INSERT失败回滚，锁表的状态不会跟着回滚，锁还牢牢占着，很容易引发死锁或并发问题。

2. SET autocommit=0能维持事务上下文的一致性 #

SET autocommit=0是关闭当前会话的自动提交模式——此时所有操作都会处于一个持续开启的事务中，直到你显式执行COMMIT或ROLLBACK。这时候执行LOCK TABLES不会触发任何隐式提交，锁表操作和后续的业务操作会完全处于同一个事务上下文里：

SET autocommit = 0;
LOCK TABLES my_table WRITE; -- 无隐式提交，事务保持开启
INSERT INTO my_table VALUES (1);
COMMIT; -- 原子提交所有操作（锁表+INSERT）
UNLOCK TABLES; -- 最后解锁表

这样一来，要么所有操作成功提交并解锁，要么全部回滚并释放锁，完美保证了原子性。

3. UNLOCK TABLES的隐式提交特性 #

还有个容易忽略的点：UNLOCK TABLES执行时，如果当前有未提交的事务，它会自动隐式提交该事务。如果用START TRANSACTION的流程，你可能会误以为COMMIT是提交整个事务，但实际上LOCK TABLES已经提前触发了一次隐式提交，最后UNLOCK TABLES又可能触发一次，整个流程的事务边界完全混乱了。而用SET autocommit=0的话，你先显式COMMIT结束事务，再执行UNLOCK TABLES，就完全避免了这个问题。

额外提醒：InnoDB更推荐行锁而非LOCK TABLES #

其实官方文档这么强调，也是因为LOCK TABLES是为MyISAM这类非事务引擎设计的表级锁机制，对InnoDB来说，用SELECT ... FOR UPDATE这类事务级行锁能获得更好的并发性能。但如果业务场景必须用到LOCK TABLES，那就严格遵循SET autocommit=0 → LOCK TABLES → 操作 → COMMIT → UNLOCK TABLES的流程，别踩隐式提交的坑。

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