查被锁行应优先用 performance_schema.data_locks（MySQL 8.0）或解析 SHOW ENGINE INNODB STATUS 的 RECORD LOCKS 段，INFORMATION_SCHEMA.INNODB_LOCKS 已移除；LOCK_DATA 字段显示主键值，需结合 transactions 表定位线程与SQL。
查当前被锁住的行记录用哪个视图
直接看 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，但这两张表本身不暴露“哪一行被锁”，真正能定位到具体行的，是 INFORMATION_SCHEMA.INNODB_LOCKS（MySQL 5.7）或其替代机制（MySQL 8.0+ 已移除该表）。
实际操作中，更可靠的是组合查询：INFORMATION_SCHEMA.INNODB_TRX 找出事务ID和SQL，再关联 performance_schema.data_locks（MySQL 8.0）或解析 SHOW ENGINE INNODB STATUS 输出里的 RECORD LOCKS 段。
常见错误是只查 INNODB_TRX 就以为锁住了某条数据——它只告诉你有事务在跑、状态如何，不告诉你锁了哪行。
MySQL 8.0 怎么查某行正在被谁锁
启用 performance_schema 并确保相关消费者已打开：data_locks、data_lock_waits、transactions。否则查 performance_schema.data_locks 返回空。
关键步骤：
- 确认变量已开启：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'global_instrumentation' OR NAME LIKE 'thread%'; - 查锁信息：
SELECT ENGINE_TRANSACTION_ID, INDEX_NAME, OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_MODE, LOCK_DATA FROM performance_schema.data_locks; - LOCK_DATA 字段值就是被锁行的主键值（如
123）或唯一索引值（如'user_abc'），注意它可能是 NULL（表示间隙锁或表级锁） - 通过
ENGINE_TRANSACTION_ID关联performance_schema.transactions查出对应线程ID和原始SQL
容易踩的坑：LOCK_DATA 不是所有存储引擎都支持，InnoDB 可以，MyISAM 完全不适用；另外，如果事务刚启动还没执行 UPDATE/SELECT ... FOR UPDATE，data_locks 里可能还没记录。
SHOW ENGINE INNODB STATUS 能不能定位到具体行
能，但得手动解析，而且只反映快照时刻的状态，不是实时流式监控。
执行后重点找 ---TRANSACTION 块和紧随其后的 RECORD LOCKS 段。其中类似这样的行：
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `test`.`t_user` trx id 123456789 lock_mode X locks rec but not gap lock held on record
说明事务 123456789 在 t_user 表主键索引上持有一个记录锁（非间隙），而下一行通常会给出具体主键值，比如：
0: len 4; hex 8000007b; asc {;这串十六进制 8000007b 解码就是十进制 123（主键值）。工具如 mysqlbinlog 或在线 hex-to-int 转换器可辅助解读。
性能影响：频繁执行 SHOW ENGINE INNODB STATUS 本身开销不大，但输出量大、人工解析成本高，不适合自动化告警。
为什么 SELECT ... FOR UPDATE 有时没锁住预期的行
根本原因是 InnoDB 锁的是索引，不是“表中的第几行”。没走索引、走了全表扫描、或者条件命中的是二级索引但没覆盖查询字段，都会导致锁范围远超预期。
典型场景：
- WHERE 条件字段没建索引 → 触发表级锁（实际是聚簇索引所有记录逐个加锁）
- 用
LIKE '%abc'导致索引失效 → 同样可能锁全表 - UPDATE 使用非唯一索引，且该索引值重复 → 会锁住所有匹配索引项对应的聚簇索引记录 + 间隙
- 事务隔离级别为
READ COMMITTED时，语句执行完就释放记录锁（不等事务结束），看起来“没锁住”
验证是否真锁了某行：另起一个事务执行相同 SELECT ... FOR UPDATE，如果卡住，说明前一个事务确实持有锁；如果立刻返回，要么没锁，要么锁已释放，要么你查的根本不是同一行（比如主键写错）。
最常被忽略的一点：锁行为高度依赖执行计划。explain 一下你的语句，确认 type 是 const、eq_ref 或 ref，而不是 ALL 或 index。否则你以为只锁1行，实际锁了几千行。
