Lock wait timeout exceeded 错误发生在执行器阶段，因InnoDB在逐行扫描、加锁（如record lock、gap lock、auto-inc lock）时遭遇阻塞，等待超时（默认50秒）；根本原因包括未提交事务、长事务、全表扫描、DDL阻塞等，而非解析或优化阶段。
为什么 Lock wait timeout exceeded 错误总在执行器阶段爆发
这个错误不是在解析或优化阶段报的，而是在执行器真正尝试获取行锁（或元数据锁）时卡住超时。InnoDB 的锁请求发生在执行器逐行扫描、判断、修改数据的过程中——比如 UPDATE 遇到已加锁的记录，DELETE 检查唯一索引冲突，甚至 INSERT 在自增主键场景下争抢 auto-inc lock。此时事务已开启、语句已编译，但资源拿不到，只能等。
常见诱因包括：
-
SELECT ... FOR UPDATE或UPDATE语句没提交，后续同表操作全被阻塞 - 长事务持有锁时间过长，比如事务里混了 HTTP 调用、文件读写等外部耗时操作
- 批量
INSERT使用innodb_autoinc_lock_mode=1（默认），整条语句执行完才释放自增锁，高并发下形成排队 - 未走索引的
WHERE条件导致全表扫描，锁住大量无关行，扩大锁竞争面
如何快速定位正在堵路的事务和锁源
别只看 SHOW FULL PROCESSLIST ——它只显示“当前状态”，未必反映真实锁持有者。真正管用的是三张表联动查：
- 先查活跃事务：
SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'RUNNING'，重点关注trx_started时间和trx_mysql_thread_id - 再查锁等待关系：
SELECT * FROM performance_schema.data_lock_waits（MySQL 8.0+）或SELECT * FROM information_schema.innodb_lock_waits（5.7 及更早） - 最后关联线程：
SELECT ID, USER, HOST, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID IN (blocking_trx_id, waiting_trx_id)
注意：如果看到 STATE 是 Waiting for table metadata lock，说明是 DDL（如 ALTER TABLE）在等 MDL，而不是行锁问题，排查路径完全不同。
innodb_lock_wait_timeout 调大真能解决问题？
不能。它只是把“超时报错”往后拖，掩盖了根本问题。比如从 50 秒调到 500 秒，用户等得更久，数据库连接池可能先撑不住了。而且该参数只影响当前会话（除非显式设为 GLOBAL），且修改后对已有连接无效。
更关键的是：它对元数据锁（MDL）完全无效 —— MDL 等待超时由 lock_wait_timeout 控制，两者是独立参数。混淆这两个值是线上事故的高频原因。
-
innodb_lock_wait_timeout：控制 InnoDB 行锁/间隙锁等资源等待上限，单位秒，默认 50 -
lock_wait_timeout：控制 MDL 等服务器层锁等待上限，单位秒，默认 31536000（1 年） - 改
GLOBAL值需重启或新连接才生效，SESSION级设置仅对当前连接有效
执行器阶段锁请求顺序到底怎么走
InnoDB 执行器不是“一口气加完所有锁”，而是边扫描边加锁、边判断边释放（部分场景）。典型顺序如下：
- 对于
UPDATE t SET c=1 WHERE id=100：先通过主键索引定位到id=100对应的聚簇索引记录 → 尝试加record lock→ 成功则更新，失败则等待 - 对于
UPDATE t SET c=1 WHERE name='a'（name有二级索引）：先查name索引拿到主键值 → 再去聚簇索引加锁 → 若二级索引本身也要维护唯一性，还会对name索引记录加锁 - 对于范围更新
UPDATE t SET c=1 WHERE id BETWEEN 10 AND 20：按主键顺序逐行加锁，过程中可能触发gap lock或next-key lock，锁住区间而非单点 - 对于
INSERT：先检查唯一约束（加insert intention lock），再插入记录（加record lock），自增主键还涉及auto-inc lock协调
这意味着：锁冲突点往往不在 SQL 表面的 WHERE 条件，而在执行器实际访问的索引路径上。没走索引的查询，等于让执行器扛着锁扫完整张表。
