MySQL行锁和表锁如何区分_通过explain查看锁等待机制.txt

MySQL行锁按索引记录加，WHERE不走索引会导致全表扫描并加临键锁，甚至升级为表锁；唯一索引下WHERE id=1仅加记录锁，非唯一索引则加临键锁；ORDER BY+LIMIT是否缩小锁范围取决于是否命中索引。WHERE 条件没走索引，全表扫描就等于全表加锁MySQL 的行锁（比如 UPDATE 或 SELECT ... FOR UPDATE）不是按"行"加的，而是按"索引记录"加的。如果 WHERE 条件无法命中索引，InnoDB 只能走聚簇索引全扫描------这时每条记录都会被加上临键锁（next-key lock），锁住整个范围，甚至可能升级为表锁。常见错误现象：SHOW ENGINE INNODB STATUS 里看到大量 RECORD LOCKS，但业务只改一行，却卡住其他无关更新使用场景：高并发下单、库存扣减、账户余额变更等对一致性要求高的写操作验证是否走索引：务必用 EXPLAIN 看 type 是否为 range/ref/const，且 key 列非 NULL注意隐式类型转换：比如 user_id 是 INT，但传了字符串 '123'，会导致索引失效 → 全表锁联合索引顺序错，等于白建联合索引 (a, b, c) 能加速 WHERE a=1 AND b=2，但对 WHERE b=2 AND c=3 完全无效------不仅查不到，而且加锁也会落到聚簇索引上，锁住所有满足 b=2 的行（即使 c 不匹配）。参数差异：WHERE a=1 锁的是索引中 a=1 对应的所有索引项；WHERE a=1 AND b>2 锁的是 (a=1, b>2) 的临键区间，范围更小容易踩的坑：把高频过滤字段放在联合索引后位，比如 (created_at, user_id)，但查询总以 user_id 为条件 → 索引失效 → 加锁变宽性能影响：错误顺序会让原本只锁几十行的操作，变成锁几千行，阻塞明显SELECT ... FOR UPDATE 在唯一索引和非唯一索引下加锁行为完全不同这是最容易被忽略的细节：同样是 WHERE id = 123，如果 id 是主键或唯一索引，InnoDB 只加一条记录上的记录锁（record lock）；但如果 id 是普通索引（哪怕有唯一约束但没定义为 UNIQUE），就会加临键锁（next-key lock），锁住该值前后的间隙。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。