Lock wait timeout exceeded 错误源于 MySQL 服务端，表示 SQL 获取锁时因其他事务未提交而超时；需通过 information_schema 查询阻塞事务并 KILL thread_id 终止，同时配置 innodb_lock_wait_timeout 等参数优化。
Lock wait timeout exceeded 是数据库报的，不是 DBeaver 报的
这个错误信息 Lock wait timeout exceeded 一定来自数据库服务端（比如 MySQL），DBeaver 只是把错误原样透传出来。它意味着：当前 SQL 尝试获取某行/表的锁时，被另一个长期未提交的事务占着，等超时了。DBeaver 自身没有“锁等待超时”这个独立配置项，它的行为完全取决于 JDBC 驱动和数据库服务端设置。
MySQL 中如何定位和终止阻塞事务
在 DBeaver 里执行以下查询，能快速看到谁在锁、谁在等：
SELECT * FROM information_schema.INNODB_TRX\G SELECT * FROM information_schema.INNODB_LOCK_WAITS\G SELECT * FROM information_schema.INNODB_LOCKS\G
关键字段说明：
-
TRX_ID和TRX_MYSQL_THREAD_ID：对应会话 ID，可用于 kill -
TRX_QUERY：当前正在执行的语句（可能为空，说明事务空闲但未提交） -
TRX_STARTED：事务开始时间，超过 5 分钟还没提交的基本可怀疑
确认后，用 KILL [thread_id] 终止阻塞源（注意不是 KILL QUERY，要 KILL CONNECTION）。
避免下次再触发的关键配置
单纯调大超时值治标不治本，真正要防的是长事务和隐式事务。以下配置建议直接加到 DBeaver 连接的【编辑连接】→【驱动属性】中：
-
wait_timeout=60：MySQL 服务端空闲连接断开时间（单位秒），防止连接挂太久还占着锁 -
interactive_timeout=60：同上，针对交互式连接（DBeaver 默认走这个） -
innodb_lock_wait_timeout=30：这是控制Lock wait timeout exceeded的核心参数，单位秒，建议设为 30～60，太大会让问题更隐蔽 - 禁用自动提交：
autocommit=false要谨慎——DBeaver 默认是 true，手动改 false 后必须显式COMMIT或ROLLBACK，否则事务一直挂着
特别注意：innodb_lock_wait_timeout 是 MySQL 实例级参数，如果没权限改全局配置，只能在当前会话里临时设：SET innodb_lock_wait_timeout = 30;
DBeaver 界面操作容易忽略的锁风险点
很多用户根本没意识到，某些看似“只读”的操作在 DBeaver 里也会开启事务并持锁：
- 在数据编辑器里双击某行进入编辑模式 → DBeaver 自动开启事务，直到你点 ✅ 提交或 ❌ 取消
- 执行
UPDATE或DELETE后没点“应用更改”，就切到其他标签页 → 事务仍活跃，锁未释放 - 使用“导出结果集”功能时勾选了“包含 INSERT 语句”，DBeaver 会先查全量再拼 SQL → 大表可能触发间隙锁或表级锁
- 批量修改多行后只提交部分 → 剩余未提交行持续占用行锁
最稳妥的习惯：做完数据修改立刻点工具栏的 Commit 或 Rollback 按钮，别依赖自动提交，也别靠关标签页来“结束”事务。
