SQL锁机制怎么理解_完整逻辑拆解助力系统化掌握【指导】

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锁”。没有它，加表锁前就得全表扫描检查行锁，性能灾难。

锁粒度影响并发，但不是越小越好

行锁并发高，表锁开销低，选择要看访问模式：

标签： mysql 并发访问 无锁 有锁