SQL锁机制的核心作用是协调并发事务对同一数据的访问，防止脏读、不可重复读和幻读；它依操作类型、索引、隔离级别和引擎动态生效，分为全局锁、表锁、行锁，以及共享锁、排他锁、意向锁，还有记录锁、间隙锁、临键锁等实现方式。
SQL锁机制的核心作用，是协调多个事务对同一数据的并发访问，防止出现脏读、不可重复读、幻读等不一致问题。它不是“加了就万事大吉”的开关，而是根据操作类型、索引结构、隔离级别和引擎特性动态生效的一套协同规则。
按粒度分：全局锁、表锁、行锁怎么选
锁的粒度直接决定并发能力与资源争用程度：
-
全局锁（
FLUSH TABLES WITH READ LOCK）：锁住整个实例，所有表只读。适合全库逻辑备份，但业务会停写，主从同步也会卡住；InnoDB 更推荐用--single-transaction参数做无锁一致性备份。 -
表级锁：MyISAM 默认方式，
LOCK TABLES ... READ/WRITE。开销小、加锁快，但一锁整张表，写操作多时容易成为瓶颈。 - 行级锁：InnoDB 默认行为，实际锁定的是索引记录（主键或二级索引）。只有在有合适索引时才真正生效；没索引会退化为表锁。
按用途分：共享锁、排他锁、意向锁各干啥
它们解决的是“谁可以读、谁可以写、谁打算读写”的权限划分问题：
-
共享锁（S锁）：用
SELECT ... LOCK IN SHARE MODE显式加，允许多个事务同时读，但阻塞写。适合需要读取后校验、但不立即修改的场景。 -
排他锁（X锁）：用
SELECT ... FOR UPDATE或 DML（UPDATE/DELETE）自动触发，当前事务独占读写权，其他事务无法加S锁或X锁。 - 意向锁（IS/IX）：InnoDB 自动加的表级标记，不需手动操作。比如事务要对某行加X锁，会先在表上加IX锁——告诉别人“我下面要锁行”，避免每次检查都扫全表。
按实现分：记录锁、间隙锁、临键锁怎么配合
这是InnoDB在可重复读（RR）隔离级别下保障范围查询一致性的关键组合：
-
记录锁（Record Lock）：锁定索引中的具体值，比如
WHERE id = 5就锁住id=5那条记录。 -
间隙锁（Gap Lock）：锁定两个索引值之间的空隙，如
WHERE age BETWEEN 20 AND 30会锁住(20,30)这个区间，阻止插入age=25的新记录。 - 临键锁（Next-Key Lock） = 记录锁 + 间隙锁，是InnoDB默认的行锁算法。它既防改已有记录，也防插新记录，从而解决幻读。
实战中几个容易踩的坑
锁不是写完SQL就自动最优的，很多问题出在细节判断上：
- UPDATE/DELETE 没走索引 → 触发全表扫描 → 实际加的是表锁，不是行锁。
- WHERE 条件含函数或类型隐式转换（如
WHERE phone = 13800138000，而phone是字符串字段）→ 索引失效 → 同样可能升级为表锁。 - 事务里只查不更新，却用了
FOR UPDATE→ 白占锁、延长锁持有时间 → 增加死锁风险。 - 高并发下单条记录频繁更新 → 多个事务排队等同一行X锁 → 表现为响应延迟突增，不是数据库慢，是锁在排队。
基本上就这些。理解锁，重点不在背类型，而在看懂“什么操作、走什么索引、在什么隔离级别下，最终锁住了什么”。
