state显示“waiting for row lock”说明当前线程正等待innodb行锁释放，本质是被其他事务阻塞而非sql执行慢；其time持续增长、耗时波动大、info中sql简短带索引却无响应，需联查innodb_trx与innodb_lock_waits定位blocking_pid及空blocking_query所暗示的未提交事务。
State显示Waiting for row lock说明什么
这表示当前线程正在等待InnoDB行锁释放，不是SQL本身慢，而是被别的事务卡住了。它和Sending data、Sorting result这类执行中状态有本质区别——后者是真在干活，前者是干不了活，在门口排队。
常见现场特征：
-
State列明确出现Waiting for row lock，且Time持续增长（比如从5秒涨到60秒） - 同一批UPDATE/DELETE语句，在不同时间执行耗时差异极大（100ms vs 5s），波动剧烈
-
Info列里SQL看起来很短、条件也带索引，但就是不动
查INNODB_TRX + INNODB_LOCK_WAITS联表定位阻塞链
单看SHOW PROCESSLIST只能知道“谁在等”，不知道“被谁挡”。必须用系统表挖出完整阻塞关系：
MySQL 5.7及之前：
SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, r.trx_query AS waiting_query, b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread, b.trx_query AS blocking_query FROM information_schema.INNODB_LOCK_WAITS w JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;
MySQL 8.0+ 更推荐直接查sys.innodb_lock_waits：
SELECT waiting_pid, blocking_pid, waiting_query, blocking_query FROM sys.innodb_lock_waits\G
关键点：
-
blocking_pid对应的就是真正持锁的线程ID，要KILL的是它，不是报错的那个 -
blocking_query为空 ≠ 没问题，可能SQL已执行完，但事务没提交（START TRANSACTION后忘了COMMIT或ROLLBACK） - 如果
blocking_trx_id查不到对应线程，去PROCESSLIST里找Command = Sleep且Time很大的ID，大概率就是它
为什么EXPLAIN显示走索引，还是被锁住一大片
走索引只保证能定位到目标行，不等于只锁那一行。锁范围受隔离级别、索引类型、WHERE条件共同影响：
- RR隔离级别下，
WHERE id > 100 AND id 会加间隙锁（Gap Lock），锁住(100,200)这个范围，别人INSERT进来就卡住 - 唯一索引等值查询（
WHERE id = 123）才锁单行；非唯一索引等值查询会锁该值+下一个间隙 -
LIKE 'abc%'能走索引，但LIKE '%abc'不行 → 全表扫描 → 所有行都加锁 - UPDATE未带WHERE，或WHERE字段无索引 →
type = ALL→ 锁全表
验证是否真走索引：对疑似SQL跑EXPLAIN FORMAT=TRADITIONAL，盯type和key字段。
innodb_lock_wait_timeout调大有用吗
没用。它只是把“等多久就放弃”从50秒改成300秒，不解决“谁在占着不放”这个根本问题。
副作用更实在：
- 设成300秒后错误变少？说明你掩盖了应用层事务控制缺陷，不是优化
- 用户卡5分钟才失败，体验比5秒就报错还差
- 全局改（
SET GLOBAL innodb_lock_wait_timeout = 300）只对新连接生效，当前连接不受影响 - 会话级临时调低（
SET SESSION innodb_lock_wait_timeout = 5）反而是好办法——能快速复现问题，逼出隐藏的长事务
真正该盯的是INNODB_TRX里trx_state = 'RUNNING'且trx_started超过60秒的事务，尤其是trx_query为空或明显在做非DB操作（如SLEEP()、HTTP调用）的那些。
