连接超时源于JDBC驱动而非DBeaver，需按建连、登录、查询、空闲断开四类场景分别配置connectTimeout（TCP握手）、socketTimeout（读写操作）、validationInterval（连接池探活）、QueryTimeout（UI层SQL中断）等参数，单位均为毫秒，且多层超时值须合理嵌套避免倒挂。
连接超时不是DBeaver的问题，而是JDBC驱动在等网络或数据库响应时“放弃”的结果。关键得看是哪一环断了：建连失败、登录卡住、查询挂起，还是空闲后自动断开——每种对应不同参数，混着调只会让问题更难定位。
connectTimeout 和 socketTimeout 到底管什么
这两个参数都得填进连接的【高级参数】里，但作用完全不同：
-
connectTimeout：只管“TCP握手”那几秒。设太小（比如 1000），局域网偶尔抖动就报Connection refused或直接超时；设太大（如 300000），DNS解析慢或目标端口彻底不通时，你会干等5分钟才失败 -
socketTimeout：管建连之后的所有读写操作。查一张大表、导出百万行、执行带锁的 UPDATE，卡在这一步就会触发它。MySQL 默认不设，容易导致 DBeaver 界面假死；PostgreSQL 推荐设120000（2分钟），避免长事务拖垮整个连接池 - 它们单位都是毫秒，别错填成秒。填
60和60000效果天差地别
空闲连接断开后重连慢，光调 DBeaver 没用
现象是：放着 DBeaver 不动 10 分钟，再点查询，要卡 10–20 秒才恢复——这不是 DBeaver 卡，是它发现连接已失效，正在重新走完整建连+认证流程。
- 先确认数据库侧的空闲超时值：
SHOW VARIABLES LIKE 'wait_timeout'（MySQL）或SHOW PARAMETER interactive_timeout（PostgreSQL）。如果数据库只等 300 秒（5 分钟），DBeaver 再怎么设validationInterval=30000都救不了 - DBeaver 侧要启用连接有效性验证：
testOnBorrow=true+validationQuery=SELECT 1+validationInterval=30000。这能让它在借出连接前快速探活，而不是等执行 SQL 才发现断了 - 如果走 SSH 隧道，别漏掉 SSH 设置里的「通道连接超时」——它独立于数据库超时，设太短会提前关隧道，导致后续所有数据库操作失败
QueryTimeout 是 UI 层唯一可控的“强制中断”开关
这个参数决定 DBeaver 在界面上主动取消一条 SQL 的时机，和 JDBC 层的 socketTimeout 不冲突，但优先级更高。
- 在「首选项 → 数据库 → 编辑器 → SQL 编辑器」里设置
Query Timeout（单位：秒）。设为60，意味着执行超过 1 分钟的查询会被 DBeaver 主动发 cancel 请求 - 它只影响你手动执行的 SQL，不影响后台元数据加载、自动补全、结果集分页这些操作
- 注意：某些旧版 Hive JDBC 驱动不支持 cancel，即使设了也无效；此时必须靠
socketTimeout做兜底
真正麻烦的是多层超时叠加：数据库 wait_timeout、SSH tunnel timeout、JDBC connectTimeout/socketTimeout、DBeaver 的 QueryTimeout 和 result_set_cancel_timeout —— 它们数值不能倒挂，比如数据库只活 300 秒，你却把 validationInterval 设成 60000（1 分钟），等于每分钟白验一次早就断掉的连接。调参前，先用 SHOW PROCESSLIST 或 pg_stat_activity 看清连接实际生命周期在哪一环终结。
