sql锁机制的核心是保障并发一致性，关键在于理解语句在何种条件下锁住哪些数据：行锁依赖索引，WHERE条件是否命中唯一索引决定锁粒度；UPDATE/delete一体化加锁；select显式语句或SERIALIZABLE级别会加锁；死锁源于资源申请顺序冲突，预防需统一访问顺序。
SQL锁机制的核心，是数据库在并发环境下保障数据一致性的“交通规则”。它不靠强制排队，而是靠精确标记哪些数据正在被谁用、怎么用——理解它，关键不是背类型，而是看懂“什么语句、在什么条件下、锁住了什么、为什么锁成这样”。
行锁不是自动生效的，得靠索引“指路”
很多人以为SELECT ... for UPDATE天然只锁一行，其实不然。真正决定锁粒度的，是WHERE条件是否命中唯一索引（如主键）：
- ✅
SELECT * FROM user WHERE id = 100 FOR UPDATE→ 只锁id=100这一行（记录锁） - ⚠️
SELECT * FROM user WHERE name = '张三' FOR UPDATE→ 若name无索引，会全表扫描并锁住所有行；若有普通索引但非唯一，可能触发next-key锁（记录+间隙），锁住整个搜索范围 - ❌ 没有WHERE、或WHERE条件无法走索引 → InnoDB退化为表级锁（逻辑上锁全表，实际是锁所有聚簇索引页）
UPDATE/DELETE不是“先查再改”，而是一体化加锁操作
执行UPDATE order SET status = 'paid' WHERE order_no = 'ORD20251213001'时，mysql不会先做一次SELECT再更新。它直接按WHERE定位，对扫描到的每条匹配记录施加排他锁（X锁）。这个过程包含两个隐含事实：
- 如果order_no是主键：只锁这一行，其他订单不受影响
- 如果order_no只是普通索引：InnoDB会先通过该索引找到记录，再回表查主键，此时二级索引记录和对应主键记录都会被加X锁
- 若WHERE条件是范围（如
WHERE create_time > '2025-12-01'），即使有索引，也会用next-key锁锁定满足条件的所有索引区间，防止幻读
看似只读的SELECT，也可能悄悄加锁
默认情况下，普通SELECT是快照读（不加锁），但以下情况会主动上锁：
-
SELECT ... LOCK IN SHARE MODE→ 加S锁，允许别人读，但禁止别人写 -
SELECT ... FOR UPDATE→ 加X锁，别人读写都阻塞（常用于“查-改”原子操作） - 事务隔离级别为SERIALIZABLE时 → 所有SELECT自动转为
FOR UPDATE等效行为 - 在可重复读（RR）下，即使没显式加锁，某些UPDATE/DELETE的扫描路径仍会触发间隙锁，间接影响SELECT结果（比如阻止新数据插入导致幻读）
死锁不是偶然，是资源申请顺序冲突的必然结果
真实业务中常见场景：
- 事务A：先锁user(id=100)，再试图锁order(id=500)
- 事务B：先锁order(id=500)，再试图锁user(id=100)
只要两个事务执行节奏稍有重叠，就构成循环等待。MySQL检测到后会主动kill其中一个事务（报Deadlock found），另一个继续。预防重点不是避免加锁，而是统一资源访问顺序：比如所有业务都约定“先锁用户，再锁订单”，或用主键ID升序批量处理。
基本上就这些。锁机制不复杂，但容易忽略索引和隔离级别的实际影响。写SQL前多问一句：“我这条语句到底会锁住哪些数据？有没有更窄的索引能帮它少锁点？”——这比死记锁类型管用得多。