mysql行级锁失效的原因排查_检查查询条件与执行计划

根本原因是查询未走索引，导致InnoDB无法精准定位单行而退化为表级锁或过大范围间隙锁；必须通过唯一索引精确匹配才能实现真正的行锁。为什么 SELECT ... FOR UPDATE 没锁住该锁的行根本原因往往是查询没走索引，导致 MySQL 退化为表级锁或间隙锁范围过大。InnoDB 行锁只在通过**唯一索引（含主键）精确匹配**时才真正锁定单行；否则可能锁住索引区间、甚至整张表。检查 EXPLAIN 输出：如果 type 是 ALL 或 index，说明没走有效索引，行锁大概率失效确认 WHERE 条件字段是否有索引：比如用 name = 'Alice' 但 name 没建索引，就会全表扫描 + 锁所有聚簇索引记录注意隐式类型转换：如 id 是 INT，但写成 WHERE id = '123'，MySQL 可能放弃索引，触发全扫描字符串字段要留意字符集和排序规则：utf8mb4_bin 和 utf8mb4_0900_as_cs 不兼容时，即使有索引也可能无法使用执行计划里 key 为空但语句明明用了索引字段常见于索引失效场景------不是"有没有索引"，而是"能不能用上"。MySQL 优化器判断走索引不划算，或条件破坏了索引最左前缀原则，就会跳过索引。复合索引 (a, b, c)，只查 WHERE b = 1 或 WHERE c = 1，key 一定为空WHERE a > 10 AND b = 2 可能只用到 a，b 变成过滤条件，不参与索引查找对索引字段使用函数或运算：WHERE YEAR(create_time) = 2024 或 WHERE status + 0 = 1，索引直接失效OR 连接不同字段时，除非所有字段都有独立索引且被合并，否则容易退化为全表扫描事务中锁住的到底是哪些行：看 INFORMATION_SCHEMA.INNODB_TRX 和 INNODB_LOCKS别靠猜，得查实时状态。MySQL 8.0+ 已移除 INNODB_LOCKS，改用 performance_schema.data_locks；但老版本仍可依赖前者辅助定位。 知网AI智能写作 知网AI智能写作，写文档、写报告如此简单