DBeaver空闲断连是因默认不维持连接，需同时配置连接保持（设为30–120秒）、socketTimeout（如60秒）和SSH通道超时（≥数据库wait_timeout），三者协同生效。
连接空闲后自动断开，不是 DBeaver “坏了”，而是它默认启用了连接保活机制的反向策略：不主动维持空闲连接。关键在两个地方——连接保持（客户端心跳）和 socketTimeout（网络层超时），漏掉任意一个，都会导致你切回来时卡住、报错或假死。
连接设置里的「连接保持」必须显式开启
这个选项控制 DBeaver 主动发心跳包维持连接，否则数据库侧一旦触发 wait_timeout（MySQL）或 tcp_keepalives_idle（PostgreSQL），连接就静默断开了。
- 右键目标连接 → 编辑连接 → 切到【初始化】标签页
- 勾选
连接保持，值设为60（单位秒，建议 30–120 之间） - 不勾选时，DBeaver 完全不发任何保活请求，纯靠 JDBC 驱动底层行为，多数驱动默认是关闭的
- 注意：该设置只对新建立的连接生效，已断开的连接需手动重连才能应用
高级参数里要配对 socketTimeout 和 connectTimeout
socketTimeout 决定单次查询/读取的最大等待时间，但它也间接影响空闲判断——如果设得太短（比如 5 秒），一次简单 SELECT 1 都可能因网络抖动超时，触发连接误回收；设得太长（如 300 秒），又会让“假死”状态持续很久。
- 进【驱动属性】或【高级参数】页，添加或修改这两项：
-
socketTimeout=60000（60 秒，适合大多数生产环境） -
connectTimeout=30000（30 秒，控制建连阶段） - MySQL 推荐搭配
validationQuery=SELECT 1+testOnBorrow=true，确保每次从连接池取连接前都做可用性检查 - PostgreSQL 用户注意：
socketTimeout超过 120 秒时，需同步调大服务端的tcp_keepalives_idle，否则系统 TCP 层先断链
用 SSH 隧道时，别忘了「通道连接超时」
很多用户只调了数据库连接参数，结果还是断——因为实际链路是 DBeaver → SSH 客户端 → 远程服务器 → 数据库，中间 SSH 层有自己的空闲断连逻辑。
- 编辑连接 → 切到【SSH】标签页（如有启用）
- 找到
通道连接超时（Channel connection timeout），设为60或更高 - 该值应 ≥ 数据库侧的
wait_timeout，否则 SSH 先断，DBeaver 还没反应过来 - 若使用密钥登录且未配置
ServerAliveInterval，可在 SSH 配置中追加：ServerAliveInterval 30（写在 ~/.ssh/config 里）
真正容易被忽略的是三者协同：数据库服务端的超时参数（如 MySQL 的 wait_timeout）、SSH 层的保活、DBeaver 自身的 连接保持 和 socketTimeout。它们像齿轮一样咬合，差一齿，空闲断连就照常发生。
