sql加锁发生在执行器逐行扫描并访问数据的过程中——即动态加锁阶段，而非解析或生成执行计划时；具体时机取决于隔离级别、索引类型、where条件和语句类型。
SQL执行过程中，加锁发生在哪个阶段？
MySQL加锁不是在“解析SQL”或“生成执行计划”时统一完成的，而是在**执行器逐行扫描并访问数据的过程中动态加锁**——具体时机取决于隔离级别、索引类型、WHERE条件和语句类型。例如：UPDATE语句在InnoDB中会边定位记录、边加X锁；而SELECT ... FOR UPDATE则在读取每一行满足条件的记录时立即加锁。
- 普通
SELECT（无FOR UPDATE或LOCK IN SHARE MODE）在READ COMMITTED和REPEATABLE READ下通常不加锁，靠MVCC快照读实现一致性 -
DELETE/UPDATE语句：先按WHERE条件扫描（可能走索引或全表），对**每一条命中且需修改的记录**加X锁；若使用非唯一索引，还可能在二级索引和聚簇索引上分别加锁 - 范围查询（如
WHERE id > 100）在REPEATABLE READ下会额外加gap lock或next-key lock，防止幻读——这发生在扫描到间隙时，而非仅在记录上 - 没有索引的
WHERE条件会触发全表扫描，导致整张表的每条记录都被加锁（严重降低并发）
为什么SELECT ... FOR UPDATE有时锁住的不止一行？
这不是bug，而是InnoDB为保证可重复读和防止幻读所采用的临键锁（next-key lock）策略：它 = record lock + gap lock。只要WHERE条件涉及**范围、非唯一索引或缺失索引**，就可能锁住记录本身及其前后间隙。
- 示例：
SELECT * FROM hero WHERE name = '关羽' FOR UPDATE，若name是普通二级索引（非唯一），InnoDB会在该name值对应的所有主键记录上加X锁，同时在name索引的相邻间隙加gap lock - 若
name是唯一索引，且等值查询命中单行，则只加record lock（不锁间隙） - 若
WHERE age > 25，即使age有索引，也会锁住所有满足条件的记录+它们之间的间隙，甚至右边界（如最大age之后的gap） - 在
READ COMMITTED下，InnoDB会禁用gap lock，只锁命中的记录——但这也意味着无法阻止幻读
事务提交后，锁真的立刻释放了吗？
绝大多数情况下是的，但有例外：某些锁（尤其是gap lock和next-key lock）的释放时机与事务结束强绑定，而元数据锁（MDL）的生命周期更特殊——它可能持续到语句结束，甚至整个事务结束，且不受COMMIT影响，只在语句执行完毕后由Server层主动释放。
-
record lock和gap lock：随事务COMMIT或ROLLBACK原子释放 -
MDL（元数据锁）：在语句执行完成后立即释放（哪怕在长事务中），但DDL操作会持有MDL直到事务结束，造成阻塞 - 意向锁（
IX/IS）：属于表级协调锁，随事务结束释放，不单独管理 - 显式
LOCK TABLES获得的表锁：必须用UNLOCK TABLES释放，不会被COMMIT自动清理
最容易被忽略的锁陷阱：隐式加锁和索引依赖
很多人以为“没写FOR UPDATE就不会锁”，其实不然。InnoDB对UPDATE/DELETE语句总是加锁，且锁行为完全由**实际走哪个索引路径**决定——哪怕SQL里写的字段没建索引，也可能因回表、索引合并或优化器选择而引发大面积加锁。
- 执行
UPDATE t SET status=1 WHERE phone='138...' AND create_time > '2025-01-01'，若只有phone单列索引，create_time条件会被当做过滤条件处理，但InnoDB仍需扫描所有phone匹配的行并逐个加锁 -
INSERT ... ON DUPLICATE KEY UPDATE：先尝试插入，若遇到唯一冲突，则对冲突行加S锁（用于后续更新），这个S锁可能与其他事务的X锁形成死锁 - 没有
WHERE的UPDATE或DELETE会触发全表扫描+全表加锁，务必避免 - 用
EXPLAIN确认执行计划是否走了预期索引，否则加锁范围可能远超预期
锁机制的复杂性不在语法，而在数据组织（B+树结构）、事务语义（隔离级别定义）和引擎实现（InnoDB如何把逻辑需求映射到物理锁）三者的耦合。真正踩坑的，往往不是不会加锁，而是不知道自己已经加了什么锁、加在哪儿、为什么加。
