MySQL中锁在COMMIT或ROLLBACK执行完成的那一刻才统一释放，由InnoDB两阶段锁协议决定，与隔离级别无关；隔离级别仅影响锁类型和范围。
事务提交时，锁是立即释放还是延迟释放？
MySQL 中的锁在 COMMIT 或 ROLLBACK 执行完成的**那一刻**才统一释放，不是在语句执行完、也不是在日志刷盘后。这是由 InnoDB 的两阶段锁（2PL）协议决定的：锁必须持有到事务结束，否则会破坏隔离性。
常见误解是“UPDATE 执行完就释放行锁”，实际并非如此。只要事务没提交，即使后续只读不写，那几行记录上的 X 锁仍被持有，其他事务尝试更新或加 X 锁就会阻塞。
不同隔离级别下锁的释放行为有差异吗？
锁的**释放时机**与隔离级别无关——所有级别下，锁都严格在事务结束（COMMIT/ROLLBACK）时释放。但隔离级别会影响**锁的类型和范围**，进而间接影响“何时开始持锁”和“持哪些锁”：
-
READ COMMITTED：普通SELECT不加锁；UPDATE/DELETE只锁匹配到的行，且不加间隙锁（除非唯一索引等特殊场景） -
REPEATABLE READ：SELECT ... FOR UPDATE或写操作会加临键锁（next-key lock），覆盖记录 + 间隙，锁范围更大，更容易引发锁等待 -
SERIALIZABLE：所有普通SELECT都隐式转为SELECT ... LOCK IN SHARE MODE，读也要加锁
显式 UNLOCK TABLES 能释放 InnoDB 行锁吗？
不能。UNLOCK TABLES 只影响 MySQL Server 层的表级锁（如 LOCK TABLES t1 WRITE），对 InnoDB 存储引擎的行锁、间隙锁、临键锁完全无效。InnoDB 行锁的生命周期只由事务控制，不受 UNLOCK TABLES 干扰。
如果你看到执行了 UNLOCK TABLES 后阻塞消失，大概率是因为它**隐式提交了当前事务**（当 autocommit=0 且之前有未提交事务时），从而真正触发了锁释放。
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
SET autocommit = 0; INSERT INTO t VALUES (1); -- 此时行锁已加，但事务未提交 UNLOCK TABLES; -- 在某些 MySQL 版本中会触发隐式 COMMIT，导致锁释放 -- 注意：该行为依赖版本和 SQL_MODE，不可依赖
长事务不提交会导致锁一直不释放吗？
是的。只要事务处于活跃状态（未 COMMIT 或 ROLLBACK），它持有的所有锁都会持续存在，哪怕只是执行了一条 SELECT ... FOR UPDATE 后就 sleep 了 10 分钟。
这会直接导致：
- 其他事务在修改相同记录时被阻塞，出现
Waiting for table metadata lock或更常见的Lock wait timeout exceeded - 阻塞
DDL操作（如ALTER TABLE），因为 DDL 需要获取元数据锁（MDL），而 MDL 与事务锁存在耦合 - 占用内存（锁信息存于
INFORMATION_SCHEMA.INNODB_TRX和锁队列中），极端情况下拖慢整个实例
排查方法始终从 SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX 入手，看 TRX_STARTED 时间和 TRX_STATE，再关联 INNODB_LOCK_WAITS 定位阻塞链。
锁的释放逻辑看似简单，但实际中最容易被忽略的是：事务边界是否真的结束了——比如 ORM 自动开启的事务没显式 commit、连接池复用导致上个请求的事务残留、或是异常路径下漏写了 rollback。这些都不是锁机制的问题，而是事务控制流的盲点。
