MySQL的两阶段锁协议（2PL）实为强严格两段锁（SS2PL），即事务中所有行锁（含记录锁、间隙锁、next-key锁）均在COMMIT或ROLLBACK时统一释放，不因语句执行完毕而提前释放，以此保障可串行化调度。
MySQL 的两阶段锁协议（2PL）不是一种可选配置，而是 InnoDB 在可重复读（REPEATABLE-READ）及以上隔离级别下默认强制执行的锁生命周期管理规则：事务一旦加了行锁，就不会在语句执行完就释放，而是必须等到 COMMIT 或 ROLLBACK 完成后才统一释放。
2PL 在 InnoDB 中实际就是 Strict 2PL（S2PL）
基础 2PL 理论上允许“增长阶段→收缩阶段”的切换，但 MySQL 实际不这么做。InnoDB 采用的是强严格两段锁（SS2PL），即：
- 所有行锁（包括
SELECT ... FOR UPDATE、UPDATE、DELETE触发的记录锁、间隙锁、next-key 锁）都在事务结束时一次性释放 - 事务运行中不会主动释放任何已持有的行锁，哪怕那条记录早已处理完毕
- 表级锁（如
LOCK TABLES）除外，它走的是另一套机制，不遵循此规则
这意味着你写一条 SELECT * FROM t WHERE id = 1 FOR UPDATE，然后做一堆其他操作（比如查用户、插日志），只要事务没提交，这把行锁就一直占着 id = 1 这行，别的事务想更新或加锁就会被阻塞。
哪些操作会触发 2PL 行锁？
不是所有查询都加锁。是否加锁、加什么锁，取决于语句类型、隔离级别和索引使用情况：
-
SELECT ... FOR UPDATE和SELECT ... LOCK IN SHARE MODE：明确加锁，受 2PL 约束 -
UPDATE/DELETE：对扫描并匹配的每行加 X 锁（可能含 gap 锁），即使WHERE条件最终不命中，只要扫描过，就先加锁再判断——但注意：在READ-COMMITTED下，不匹配的行锁会立即释放；而在REPEATABLE-READ下，它们也得等到事务结束 - 普通
SELECT（无锁提示）：在REPEATABLE-READ下不加行锁，靠 MVCC 版本快照读；但若走的是唯一索引等值查询且记录存在，InnoDB 可能隐式加SELECT ... LOCK IN SHARE MODE级别的锁来防止幻读——这点容易被忽略
释放时机异常情况：不是所有锁都死守到 COMMIT
虽然 SS2PL 是主线，但 InnoDB 对几类锁做了优化释放，不等事务结束：
- 不匹配
WHERE条件的行锁：仅在READ-COMMITTED隔离级别下生效；REPEATABLE-READ下仍保留 - AUTO-INC 锁：只在 INSERT 执行期间持有，语句结束即释放，与事务生命周期无关
- 某些内部临时锁（如排序缓冲区、文件排序用的磁盘临时表锁）：语句级生命周期，非事务级
- 显式
UNLOCK TABLES：释放当前会话持有的所有表锁，但不影响行锁
特别注意：REPEATABLE-READ 下，哪怕你 UPDATE 了一行又立刻 SELECT 它，这行的锁也不会提前松手——它始终绑定在事务上，直到 COMMIT 落库那一刻才真正交出。
为什么顺序会影响并发性能？
因为锁持有时间 = 从第一条加锁语句开始，到最后一条语句执行完 + COMMIT 的整个跨度。所以：
- 把热点行（如库存、账户余额）的加锁操作尽量往后放，能缩短其被锁定的时间窗口
- 例如先查订单状态、再校验权限、最后
UPDATE inventory，比反过来把UPDATE inventory放第一个更能减少锁争用 - 但如果中间有网络延迟、应用层耗时逻辑，锁依然全程挂着——2PL 不感知业务耗时，只认事务边界
真正容易被忽略的点是：你无法通过调整 SQL 顺序“绕过”2PL，只能借它来最小化热点锁的暴露时间；而一旦发生死锁，InnoDB 回滚的是事务中**加锁次数少、代价小**的那个，不是按语句顺序来的。
