业务提交订单、更新库存或执行后台任务时，MySQL偶尔返回 Lock wait timeout exceeded; try restarting transaction。重试一次可能成功，但过一阵又出现，接口响应也会越来越慢。
这类问题的关键不是哪个SQL最终超时，而是谁在它前面持有冲突锁。超时发生后，等待关系可能已经消失；只拿一条应用报错，很难判断是长事务、缺少索引、并发顺序不一致，还是异常连接忘记提交。
处理锁等待超时时，先确认报错发生在哪个事务边界内，并尽量在超时前抓取等待者与阻塞者，再根据锁对象和SQL选择最小改动。MySQL 8.0和8.4可使用Performance Schema的 data_locks 与 data_lock_waits；MariaDB和旧版本的表名、字段与可用视图可能不同，命令不能直接照搬。
先分清锁等待超时和死锁
锁等待超时表示一个事务等待冲突锁超过 innodb_lock_wait_timeout 允许的时间。死锁则是两个或多个事务形成循环等待，InnoDB检测后通常会主动选择一个事务回滚。两者都可能表现为业务失败，但证据和修复方向不同。
先从应用日志保存完整错误、请求标识、发生时间、SQL模板和事务操作顺序。不要只复制报错最后一行。ORM可能在外层自动重试或包装异常，真正等待的SQL要结合数据库会话和链路追踪确认。
查看当前等待超时设置：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
SHOW VARIABLES LIKE 'innodb_rollback_on_timeout';锁等待超时在常见默认配置下通常只回滚当前语句，而不一定回滚整个事务。应用捕获异常后继续提交，可能留下部分成功的业务状态。应核对驱动和事务框架的处理方式，确保超时后整个业务事务按设计回滚或重试。
看到 LATEST DETECTED DEADLOCK 时，要转向死锁分析；只看到Lock wait timeout，则继续建立阻塞链。不要把两者都归为数据库太忙。
在超时发生前保存等待现场
等待关系只在阻塞仍存在时可见。问题频繁出现时，先持续观察当前事务：
SELECT trx_id, trx_state, trx_started, trx_wait_started,
trx_mysql_thread_id, trx_rows_locked, trx_rows_modified,
trx_query
FROM information_schema.innodb_trx
ORDER BY trx_started;LOCK WAIT 表示事务正在等待锁，RUNNING 不代表没有持锁。一个显示RUNNING、SQL为空或连接状态为Sleep的事务，仍可能因为尚未提交而阻塞其他会话。关注事务开始时间、等待开始时间、连接ID、锁定行数和当前SQL。
同时保存完整进程列表：
SHOW FULL PROCESSLIST;SHOW PROCESSLIST 的Info可能截断SQL，排查时使用FULL。把结果与应用请求时间对齐，记录用户、来源主机、数据库和状态。不要立即执行KILL，否则最有价值的等待关系会消失。
生产库查询这些视图需要相应权限。权限不足时应使用受控诊断账号，避免临时给应用账号过大的全局权限。
用data_lock_waits找到真正阻塞者
MySQL 8可通过Performance Schema把等待锁和已持有锁关联起来：
SELECT
req.ENGINE_TRANSACTION_ID AS waiting_trx,
req.THREAD_ID AS waiting_thread,
req.OBJECT_SCHEMA,
req.OBJECT_NAME,
req.INDEX_NAME,
req.LOCK_TYPE AS waiting_lock_type,
req.LOCK_MODE AS waiting_lock_mode,
blk.ENGINE_TRANSACTION_ID AS blocking_trx,
blk.THREAD_ID AS blocking_thread,
blk.LOCK_MODE AS blocking_lock_mode
FROM performance_schema.data_lock_waits AS w
JOIN performance_schema.data_locks AS req
ON req.ENGINE_LOCK_ID = w.REQUESTING_ENGINE_LOCK_ID
AND req.ENGINE = w.ENGINE
JOIN performance_schema.data_locks AS blk
ON blk.ENGINE_LOCK_ID = w.BLOCKING_ENGINE_LOCK_ID
AND blk.ENGINE = w.ENGINE;waiting_trx 是等待者，blocking_trx 才是持有冲突锁的事务。对象库名、表名、索引名和锁模式能帮助判断冲突落在哪里。结果可能有多行，因为一个事务可以等待多个锁，一个阻塞者也可能挡住多个会话。
THREAD_ID 是Performance Schema线程ID，不一定能直接用于KILL。继续映射到连接ID和当前语句：
SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_USER,
PROCESSLIST_HOST, PROCESSLIST_TIME,
PROCESSLIST_STATE, PROCESSLIST_INFO
FROM performance_schema.threads
WHERE THREAD_ID IN (WAITING_THREAD_ID, BLOCKING_THREAD_ID);把占位值换成上一步结果。需要终止连接时使用 PROCESSLIST_ID，不要把事务ID或线程ID直接填进KILL命令。
判断阻塞者为什么长期不提交
找到阻塞连接后，先看它属于哪个应用实例、执行了哪些事务步骤，以及当前是否正在等待外部操作。常见根因是事务开启后调用远程接口、生成文件、等待用户确认，或者异常分支没有提交和回滚。
查询事务的 trx_started 和应用日志。会话处于Sleep但事务开始时间很早，通常说明连接已经暂时空闲，事务却没有结束。连接池把这种连接归还后，还可能让下一次请求继承异常事务状态。
批处理一次更新大量数据，也会长时间持有行锁。单条SQL并不慢，但事务把几千条更新包在一起，其他在线请求就会持续等待。此时应评估批次大小和提交频率，而不是只优化某一条SQL。
最小改动通常落在事务边界：把外部调用移到事务之外，所有异常路径明确回滚，缩小一次事务涉及的数据量，并为应用日志加入事务开始、提交、回滚和请求标识。
检查索引和锁定范围是否过大
更新语句缺少合适索引时，InnoDB为了查找目标记录可能扫描并锁定更多范围。先对等待SQL使用 EXPLAIN 或在测试环境使用执行分析，确认条件列和访问索引：
EXPLAIN UPDATE orders
SET status = 'paid'
WHERE user_id = 12345 AND order_no = 'A001';不要直接在生产高峰对大型写语句使用可能实际执行SQL的分析方式。普通EXPLAIN可以帮助查看访问路径，但最终锁范围还与隔离级别、索引结构、唯一性和语句类型有关。
新增索引前要评估表大小、写入成本和DDL影响。索引能减少扫描范围，却不会修复应用忘记提交的问题。查询已经准确使用唯一索引，而阻塞事务仍长期存在，应继续修复事务生命周期。
还要检查多个业务流程更新相同表时的顺序。一个流程先锁订单再锁库存，另一个先锁库存再锁订单，容易造成等待甚至死锁。统一访问顺序通常比无限延长超时更有效。
终止阻塞会话前评估回滚代价
来源明确、业务允许重试，并且阻塞事务无法正常提交或回滚时，才考虑终止连接：
KILL CONNECTION processlist_id;KILL并不等于瞬间释放全部资源。包含大量修改的事务需要回滚，回滚期间仍会消耗I/O和CPU，锁释放时间也取决于事务规模。先确认连接ID、业务请求、修改范围和幂等能力，关键订单或财务事务还要与业务负责人核对。
不建议批量终止所有Sleep连接。Sleep只表示当前没有执行语句，连接可能处于合法空闲，也可能持有未提交事务。应通过 innodb_trx 和锁等待关系证明它是阻塞者。
更危险的处理方式是直接重启MySQL。所有连接和现场证据都会消失，大事务恢复与回滚可能延长启动时间，业务写入也会整体中断。只有数据库本身失去响应、风险经过评估且没有更小恢复手段时，才把重启作为故障处置，而不是日常解锁命令。
为什么只调大innodb_lock_wait_timeout通常没用
调大等待时间可能让部分短暂冲突自行结束，但长事务和错误事务仍然存在，应用线程只会排队更久。连接池被等待请求占满后，原本局部的锁问题会扩散成整个网站超时。
调小超时也不是根治。它能让请求更快失败，却会增加重试次数；应用没有退避、幂等和完整回滚时，重试风暴可能制造更大压力。超时时间应与业务响应目标和事务长度匹配，而不是用来掩盖阻塞者。
确实需要调整时，先在会话级或受控环境验证，记录修改前后的等待时长、失败率和吞吐，再决定是否修改全局配置。配置持久化方式随MySQL版本和部署方式不同，重启后仍需复核。
线上问题不方便复现时，可以在 萤光云 建立同版本数据库副本验证事务顺序，也可以使用按小时计费的 LightNode 搭建隔离压测环境。只使用脱敏结构和测试数据，不复制生产账号、支付信息或完整用户数据。
数据库参数确认后，修复重点要回到应用事务和重试逻辑。
数据库解除当前阻塞后，应用必须把锁等待超时视为一次事务失败。先回滚当前事务，再根据业务幂等性决定是否重试；不要在原事务上下文里只重跑失败SQL。
重试应有次数上限和短暂退避，并记录每次尝试的请求标识。订单创建、扣库存和余额变更需要幂等键，确保同一业务请求不会因为重试执行两次。无法安全重试的操作应明确失败并进入人工或补偿流程。
把事务持续时间、等待时间和回滚次数纳入监控。应用侧能看到哪个接口开启了长事务，数据库侧能看到哪个用户和来源连接持锁，两边通过请求标识关联，下一次就不必靠时间猜测。
按证据链完成验收
修复后重新查询 data_lock_waits 和 innodb_trx，业务对象不应长期存在等待关系，异常长事务已经消失或得到明确解释。重复执行原业务流程时，应用不再返回Lock wait timeout，连接池使用量和接口响应时间保持稳定。
随后进行受控并发测试，覆盖正常提交、异常回滚和重试路径。确认错误发生后整个业务事务按设计回滚，不产生重复订单、负库存或部分写入；索引调整后，执行计划和锁定范围符合预期。
最终记录应能回答等待者是谁、阻塞者是谁、锁落在哪个对象、事务为什么没有及时结束、修改了什么，以及如何证明问题不再出现。只把超时时间从一个值改成另一个值，不算完成根因修复。
常见问题
应用重试后成功，还需要处理锁等待吗？
需要。偶发冲突可以通过合理重试吸收，但重复出现说明事务、索引或并发顺序存在问题。持续重试还可能掩盖响应变慢和部分写入风险。
看到Sleep连接，可以直接全部KILL吗？
不可以。先确认它是否存在于 innodb_trx，并通过 data_lock_waits 证明它正在阻塞其他事务。普通连接池空闲连接不应被无差别终止。
Lock wait timeout会自动回滚整个事务吗？
不能一概而论。常见配置下可能只回滚当前语句，具体行为受 innodb_rollback_on_timeout 和应用事务框架影响。应用应在捕获超时后明确回滚整个业务事务。
