innodb锁等待超时无法自动记录sql，需组合错误日志（开启innodb_print_all_deadlocks+log_error_verbosity=3）、information_schema视图（innodb_trx+processlist）及应用层捕获error 1205/1206并打点日志。
innodb_lock_wait_timeout 本身不记录 SQL，MySQL 也没有“自动记录超时 SQL”的内置开关。想定位谁在等锁、等了多久、等的是哪条 SQL，必须组合使用日志、状态视图和主动扫描机制。
为什么 SHOW ENGINE INNODB STATUS 不够用
SHOW ENGINE INNODB STATUS\G 只保留最近一次死锁详情，且锁等待信息（如 “WAITING FOR THIS LOCK TO BE GRANTED”）只出现在事务活跃期间，一旦超时报错退出，这部分上下文就消失了。
它不记录触发等待的原始 SQL 文本，只显示当前阻塞语句的线程 ID 和部分堆栈；你看到 updating 状态，但不知道是哪条 UPDATE 或 DELETE 引发的。
必须开启 innodb_print_all_deadlocks 并配日志轮转
死锁和锁等待超时是两回事，但它们共享底层锁检测路径。开启 innodb_print_all_deadlocks = 1 后，MySQL 会在错误日志中输出每次死锁的完整事务链（含 SQL），这是唯一能拿到「谁持有什么锁、谁在等什么」原始语句的地方。
注意：
- 必须配合 log_error_verbosity = 3（MySQL 8.0+）才能确保 SQL 被完整打印
- 错误日志需配置轮转（如 log_error_services = 'log_filter_dragnet; log_sink_syseventlog; log_sink_json' +
dragnet.log_error_filter = 'IF prio>=WARNING THEN log'\code>），否则日志暴涨失控<br>- 不要依赖 <code>log_warnings = 2</code>（已弃用），它不保证输出 SQL
用 information_schema.INNODB_TRX + PROCESSLIST 主动抓“正在等锁”的 SQL
锁等待超时发生前，事务处于 LOCK WAIT 状态，此时可通过以下方式实时捕获：
- 查询 information_schema.INNODB_TRX 找出 trx_state = 'LOCK WAIT' 的事务，记下 trx_mysql_thread_id
- 关联 information_schema.PROCESSLIST，用该 ID 查 INFO 字段——这就是正在执行、卡在锁上的原始 SQL
- 建议写成定时脚本（如每 5 秒跑一次），把结果写入表或推送告警，而不是等超时发生后再查
- 注意：ORM 框架生成的 SQL 可能被截断（如 MyBatis 默认 1024 字符），需确认 max_allowed_packet 和驱动配置是否足够
应用层必须捕获 ERROR 1205 和 ERROR 1206 并打点
MySQL 不会主动记录超时那一刻的上下文，最终还得靠业务代码兜底：
- ERROR 1205 (HY000): Deadlock found when trying to get lock
- ERROR 1206 (HY000): Lock wait timeout exceeded
这两类错误必须在 DAO 层显式 catch，并将当前方法名、参数、堆栈、SQL（若可获取）、事务 ID、连接 ID 一并记入业务日志
- 不要只记“重试”，要记“第几次重试”“上次失败耗时”“是否幂等”
- 避免日志脱敏过度：比如把 WHERE id = ? 记成 WHERE id = ***，会导致无法关联到具体行锁
真正难的不是配置几个参数，而是让锁等待过程全程可观测——从 SQL 发出、进入等待、被中断、到应用响应，每个环节都要有对应出口。漏掉任意一环（比如没开 innodb_print_all_deadlocks，或应用没打点），你就永远不知道超时到底是谁干的。
