直接查innodb_lock_waits可确认是否被锁：有记录即存在活跃锁等待链，需立即执行；requesting_trx_id为等待事务（受害者），blocking_trx_id为阻塞事务（元凶）；mysql 8.0+推荐用sys.innodb_lock_waits获取waiting_pid/blocking_pid。
更新单条数据极慢，先看是不是被锁住了
直接查 INNODB_LOCK_WAITS。只要它有记录，说明当前就有活跃的锁等待链——不是“可能”，而是“正在卡住”。这个表是快照，锁一释放就空了，必须立刻查。
执行：SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
-
requesting_trx_id是你那条慢UPDATE所属事务的 ID（受害者） -
blocking_trx_id是真正攥着锁不放的那个事务 ID（元凶） - MySQL 8.0+ 更建议用
sys.innodb_lock_waits，字段名是waiting_pid和blocking_pid，省去查INNODB_TRX转换线程 ID 的步骤
拿到 blocking_trx_id 后，别只看 PROCESSLIST
PROCESSLIST 里状态可能是 Sleep，Info 为空，但事务没提交，锁就还在。必须查 INNODB_TRX 确认真实持锁状态。
执行：SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id, trx_query FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_id = 'xxx';
-
trx_state = 'RUNNING'且trx_started时间远早于现在（比如 >60 秒），基本就是它 -
trx_query为空？正常。事务可能只执行了BEGIN或 SQL 已跑完但没COMMIT -
trx_state = 'LOCK WAIT'？说明它自己也被卡住了，锁链已形成，得继续往上追
锁定阻塞源后，怎么找到真实 SQL 和可操作线程
INNODB_TRX.trx_mysql_thread_id 是你在数据库里唯一能动手的入口。拿它去查 performance_schema.events_statements_current，才能看到正在执行的原始语句。
执行：SELECT THREAD_ID, CURRENT_SCHEMA, SQL_TEXT FROM performance_schema.events_statements_current WHERE THREAD_ID = (SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = xxx);
- 如果
SQL_TEXT为空，再查events_statements_history（需提前开启对应 instrument） - 注意：
trx_mysql_thread_id对应的是performance_schema.threads.PROCESSLIST_ID，不是THREAD_ID - 查到 SQL 后，就能反推业务代码位置——比如
SELECT ... FOR UPDATE没配COMMIT，或连接池异常导致事务未关闭
容易忽略的三个关键点
第一，INNODB_LOCKS 在 MySQL 8.0.30+ 已废弃，别再依赖它；用 performance_schema.data_locks 替代，字段更细、含义更明确。
第二，“单条数据”不等于“只锁一行”——如果 WHERE 条件没走索引，会升级为表锁或全聚簇扫描加锁，连带锁住大量无关行。
第三，SHOW ENGINE INNODB STATUS\G 的 TRANSACTIONS 部分虽全，但只保留最近 1MB 输出，高频场景下关键信息可能被刷掉；真要定位反复出现的问题，得配合 innodb_print_all_deadlocks = ON 和错误日志持续捕获。
