sql锁机制是数据库自动触发的保护行为，核心在于根据执行路径、索引和隔离级别动态加锁：主键等值查加记录锁，普通索引范围查在RR下加next-key锁，无索引条件则可能全表加锁；select默认快照读不加锁，for SHARE加S锁，FOR UPDATE及UPDATE/delete隐式加X锁；常见误区包括索引失效致锁扩大、先查后更未加锁引发丢失更新、事务过长持锁、忽略意向锁影响。
SQL锁机制的核心，是让多个事务在并发访问同一数据时“排队”或“分区域协作”，而不是直接抢着改。它不是功能开关，而是数据库自动触发的保护行为——只要事务开始、有读写动作、隔离级别不为最低，锁就可能介入。理解它，关键不在背类型，而在看清楚什么操作会触发什么锁、为什么触发、以及怎么让它少锁或多锁得准。
锁从哪里来：触发条件比语法更重要
锁不是你写了FOR UPDATE才出现，而是数据库根据执行路径+索引+隔离级别动态决定的：
- 没走索引的
WHERE（比如WHERE name LIKE '%abc%'），InnoDB会全表扫描，所有行都可能被加锁，实际变成“伪表锁” - 主键等值查询（
WHERE id = 100）→ 只锁匹配的那1行（记录锁） - 普通索引范围查询（
WHERE age > 25）→ 在可重复读（RR）下，会加next-key锁（记录锁 + 间隙锁），不仅锁住现有数据，还锁住“25到下一个age值之间”的空隙，防幻读 - READ COMMITTED隔离级别下，间隙锁被禁用，只锁记录本身，但可能引发幻读
读和写，锁的行为完全不同
别以为SELECT就一定不锁——是否加锁、加什么锁，取决于你怎么写、在哪种场景下用：
- 普通
SELECT（无提示）→ 默认快照读，不加锁，靠MVCC提供一致性视图 -
SELECT ... FOR SHARE→ 加共享锁（S锁），其他事务还能读，但不能加X锁（即不能UPDATE/DELETE） -
SELECT ... FOR UPDATE→ 加排他锁（X锁），其他事务读写全被阻塞，直到本事务提交或回滚 - UPDATE/DELETE语句 → 自动隐式加X锁，无需额外写
FOR UPDATE；但如果WHERE条件不走索引，同样会锁全表
常见误区与避坑建议
很多并发问题不是锁不够，而是锁得“太宽”或“太晚”：
- 误以为“加了索引就一定行级锁”：复合索引中，只用到了最左前缀的一部分（如索引是
(a,b,c)，却查WHERE b = 5），仍可能失效导致全表扫描加锁 - 在事务里先查后更，却不加锁：比如
SELECT balance FROM account WHERE id=1;→ 算出新余额 →UPDATE ... SET balance = ?，中间窗口期别人也读了旧值，造成丢失更新；应直接SELECT ... FOR UPDATE - 长时间持有锁：事务里混入http调用、日志打印、循环计算等耗时操作，会让锁占用时间远超必要，拖垮并发；锁应“快进快出”，查-改-提交控制在毫秒级
- 忽略意向锁的存在：虽然意向锁（IX/IS）不直接阻塞你，但它会阻止你在有行锁时对整张表加表级写锁，排查死锁时需一并查看
基本上就这些。锁机制不是越复杂越好，而是越精准越稳。看清执行计划、善用主键/唯一索引、控制事务粒度，比死记锁类型有用得多。