行锁仅在InnoDB引擎、索引命中且非全表扫描时生效；否则退化为表锁或等效表锁，需通过EXPLAIN验证索引使用，并查INFORMATION_SCHEMA.DATA_LOCKS确认实际锁类型。
直接看执行计划和锁信息，别猜。行锁只在InnoDB + 索引命中 + 非全表扫描时生效；其他情况基本是表锁或等效表锁。
查 INFORMATION_SCHEMA.DATA_LOCKS 看实际加的什么锁
这是最权威的实时判断方式，MySQL 8.0.1+ 默认启用该视图（需有PROCESS权限）：
- 先复现问题：开两个事务，一个执行
UPDATE t SET x=1 WHERE id=100但不提交 - 另一个事务执行
SELECT * FROM INFORMATION_SCHEMA.DATA_LOCKS WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 't'; - 重点看字段：
LOCK_TYPE值为RECORD→ 行锁；TABLE→ 表锁；INTENTION→ 意向锁（说明底层有行操作，但本身不冲突） - 如果看到大量
RECORD锁，且INDEX_NAME非NULL，说明锁落在索引上；若INDEX_NAME为NULL，大概率是聚簇索引全扫，等效表锁
用 EXPLAIN 预判是否走索引
行锁的前提是优化器选了索引。不走索引，InnoDB 就没法精确定位行，只能锁全表（或所有聚集索引记录）：
- 对目标语句跑
EXPLAIN SELECT ...或EXPLAIN UPDATE ... - 检查
type字段：const/ref/range→ 可能行锁；ALL或index→ 极可能退化为表锁 - 检查
key字段：为空或NULL→ 没走索引；显示具体索引名 → 有希望 - 常见踩坑点：
WHERE name LIKE '%abc'（左模糊）、WHERE id + 1 = 100（函数操作）、WHERE user_id = '123'（类型不匹配，INT字段传字符串）都会让key失效
看存储引擎和索引是否存在
这两项是硬门槛，缺一不可：
- 确认引擎：
SHOW CREATE TABLE t;中必须含ENGINE=InnoDB；MyISAM/MEMORY 引擎下UPDATE或SELECT FOR UPDATE一律是表锁 - 确认索引：
SHOW INDEX FROM t;里至少有一个索引能覆盖WHERE条件字段；没有索引的WHERE id = 100照样锁全表 - 注意唯一性影响：
PRIMARY KEY或UNIQUE索引上的等值查询只锁匹配行；普通索引会额外加间隙锁（gap lock），范围更大但仍是行级
事务未提交时观察阻塞行为
这是最朴素但有效的验证方式，适合开发/测试环境快速排查：
- 事务 A 执行：
BEGIN; UPDATE t SET v=1 WHERE id=100; -- 不 COMMIT - 事务 B 执行：
UPDATE t SET v=2 WHERE id=200;→ 若立刻成功，说明是行锁；若卡住，大概率是表锁或间隙锁覆盖了 id=200 - 关键区别点：
id=200那行本身没被 A 锁，但若 B 卡住，说明 A 的锁范围超出了单行（比如用了普通索引+范围条件，或索引失效导致全扫） - 注意隔离级别：
READ COMMITTED下SELECT FOR UPDATE不加间隙锁，REPEATABLE READ下默认加next-key lock，行为差异大
真正难的不是“怎么判断”，而是理解为什么明明写了索引、EXPLAIN也显示走了索引，却还是锁了不该锁的行——这时候得盯紧DATA_LOCKS里的LOCK_DATA值和INDEX_NAME，再回溯执行计划里有没有隐式转换或统计信息过期。索引存在 ≠ 被用，被用 ≠ 只锁一行。
