MariaDB 出现 Lock wait timeout exceeded 错误通常是因为 InnoDB 行锁等待时间超过了 innodb_lock_wait_timeout 设定值，而非真正的表锁。最推荐的解决方向是找出持有锁的事务并提交或终止，而不是单纯增加超时时间。
先说结论：解决核心在于定位阻塞源并释放锁资源，调整超时参数仅是临时规避手段。
- 先确认：查询 information_schema.INNODB_TRX 表找出处于 LOCK WAIT 状态的事务。
- 先处理：根据 trx_mysql_thread_id 终止阻塞会话或催促提交事务。
- 再验证：重试报错 SQL 并监控后续锁等待日志是否消失。
命令速用版
以下 SQL 语句可直接用于定位当前持有锁或等待锁的事务，适用于 MariaDB 10.1 及以上版本。
SELECT trx_state, trx_started, trx_mysql_thread_id, trx_query
FROM information_schema.INNODB_TRX
WHERE trx_state = 'LOCK WAIT';若需要查看锁等待详情，可配合以下命令查看引擎状态：
SHOW ENGINE INNODB STATUS;为什么会这样
该报错本质是事务等待行锁的时间超过了配置阈值，并非物理表被锁定。InnoDB 引擎使用行级锁，当事务 A 修改某行数据未提交时，事务 B 尝试修改同一行会进入等待状态，若等待时长超过 innodb_lock_wait_timeout 变量设定值，系统就会抛出 Lock wait timeout exceeded 错误。
公开资料中没有看到可靠的量化数据说明具体多少毫秒会触发，因为这完全取决于配置值和锁持有者的处理速度。常见诱因包括长事务未提交、未走索引导致锁范围扩大、或高并发下的热点行更新。
分步处理
第一步是查询当前活跃事务，锁定处于 LOCK WAIT 状态的线程 ID。执行上述命令速用版中的 SELECT 语句，记录 trx_mysql_thread_id 字段。
第二步是处理阻塞源。如果该事务是异常卡死的会话，使用 KILL 命令终止：
KILL <trx_mysql_thread_id>;如果该事务是正常业务但执行过慢，需联系开发人员优化 SQL 或加快提交速度。切勿直接调大 innodb_lock_wait_timeout 参数，这只会掩盖问题并可能导致更多线程堆积。
第三步是检查索引使用情况。使用 EXPLAIN 分析报错的 SQL 语句，确认更新或删除操作是否命中了索引。全表扫描会将锁粒度扩大到所有扫描行，显著增加锁冲突概率。
怎么验证是否生效
验证方法是重新执行之前报错的 SQL 语句，观察是否再次抛出相同错误。同时监控 MariaDB 错误日志，确认不再有大量的 Lock wait timeout 记录。
可通过以下命令检查当前锁等待超时参数的设定值，确保未被意外修改：
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';若业务恢复正常且 INNODB_TRX 表中无长时间处于 LOCK WAIT 状态的记录，可视为处理生效。
常见坑
第一个坑是误杀系统线程。KILL 命令只能针对用户会话线程，不要尝试终止后台系统线程，否则可能导致实例不稳定。
第二个坑是盲目增加超时时间。将 innodb_lock_wait_timeout 从默认值 50 秒调大到几百秒，虽然能减少报错频率，但会延长故障恢复时间，导致连接池爆满。
第三个坑是忽略外键锁。更新父表或子表时，外键约束也会产生隐式锁，排查时需同时检查关联表的事务状态。
常见问题
这是表锁还是行锁？
这是行锁等待超时。MariaDB 默认使用 InnoDB 引擎，该错误表示行锁竞争，MyISAM 引擎才会出现真正的表锁。
增加超时时间能根治吗？
不能根治。增加超时时间只能延缓报错出现，无法解决锁持有者不释放资源的根本问题。
如何预防此类问题？
预防重点在于控制事务粒度。避免在大事务中执行耗时操作，确保更新语句命中索引，并在代码中设置合理的事务超时机制。
参考来源
- MariaDB Knowledge Base, "InnoDB Lock Wait Timeout", https://mariadb.com/kb/en/innodb-lock-wait-timeout/
- MySQL Reference Manual, "InnoDB Lock Wait Timeout", https://dev.mysql.com/doc/refman/8.0/en/innodb-lock-wait-timeout.html