SQL锁机制本质是数据库并发访问的“交通规则”，通过约定锁类型、粒度与持续时间实现有序读写；加锁对象是执行路径扫描到的每条索引记录，而非最终满足WHERE条件的行。
SQL锁机制的本质，是数据库在并发场景下协调多个事务对同一数据资源访问的“交通规则”。它不靠强制阻塞，而是通过约定加锁类型、粒度和持续时间，让读写操作有序穿行，避免脏读、不可重复读、幻读和丢失更新。理解它不需要死记术语，关键抓住三点：谁在操作（语句类型）、操作什么（索引结构与扫描范围）、想达到什么效果（隔离级别与业务意图）。
锁定行为由SQL执行路径决定，不是由WHERE条件真假决定
这是最容易误解的一点。InnoDB加锁时，并不“判断”某行是否最终满足WHERE条件，而是对**执行过程中扫描到的每一条索引记录**都加锁——哪怕该行最后被WHERE过滤掉。例如：
-
UPDATE users SET status=1 WHERE name LIKE 'A%'，即使表中只有1行name='Alice'符合，只要B+树扫描经过了name='Andy'、'Alex'等前缀匹配的索引节点，这些节点对应的所有聚集索引记录（包括不满足条件的）都会被加临键锁。 - 这个规则适用于所有锁定读（
SELECT ... FOR UPDATE/LOCK IN SHARE MODE）、UPDATE、DELETE，但不适用于普通SELECT（默认一致性读，无锁）。
锁类型与用途要按操作目的区分
不同锁解决不同问题，不能只看名字，要看它“挡住谁、允许谁”：
-
共享锁（S锁）：多个事务可共读，但谁都无法写。常用于
SELECT ... LOCK IN SHARE MODE，适合需要确保数据不被他人修改的只读校验场景（如查余额再扣款前的确认）。 -
排他锁（X锁）：当前事务独占读写，其他事务连S锁都拿不到。由
UPDATE、DELETE或SELECT ... FOR UPDATE触发，是实际修改前的“占位锁”。 - 更新锁（U锁，SQL Server特有）：一种过渡锁，先加U锁防止多事务同时读同一行再争抢X锁导致死锁。MySQL不用U锁，靠临键锁+加锁顺序优化规避。
- 意向锁（IS/IX）：纯表级标记，不拦行操作，只告诉别人“我下面某行可能要加S/X锁”。没有它，加表锁前就得全表扫描检查行锁，性能灾难。
锁粒度影响并发，但不是越小越好
行锁并发高，表锁开销低，选择要看访问模式：
- 用主键或唯一索引精准定位单行 → 自动走记录锁（Record Lock），不锁间隙，效率最高。
- 用非唯一索引或范围查询（如
WHERE age BETWEEN 20 AND 30）→ 默认加临键锁（Next-Key Lock），即记录锁 + 前一个间隙锁，防幻读；若关闭间隙锁（innodb_locks_unsafe_for_binlog=ON），则退化为记录锁，但可能引发幻读。 - 显式加表锁（
LOCK TABLES t WRITE）或DDL操作（如ALTER TABLE）→ 持有元数据锁（MDL），会阻塞后续查询，需谨慎。
隔离级别决定锁的“松紧程度”
同样的SQL，在不同隔离级别下加锁行为可能完全不同：
- READ COMMITTED：每次快照读都新建版本视图，只对当前语句扫描行加锁，语句结束即释放（非事务级持锁）。
- REPEATABLE READ（InnoDB默认）：事务内首次读生成快照，后续读复用；锁定读会持续持有锁直到事务结束，且默认启用临键锁防幻读。
-
SERIALIZABLE：最严级别，普通
SELECT也自动转为SELECT ... LOCK IN SHARE MODE，所有读都加S锁，彻底串行化。
基本上就这些。真正用好锁，不是背概念，而是写完SQL后问自己三句话：我扫了哪些索引？我要阻止别人做什么？我的事务边界在哪里？答清楚，锁就自然清晰了。
