DBeaver空闲连接断开实为数据库服务端超时强制关闭，需配置高级属性中的keep-alive query（如SELECT 1）及interval（如30000毫秒）实现保活，而非依赖初始化页的connection keep-alive。
空闲连接不会自动断开——DBeaver 默认不主动关闭连接，所谓“自动断开”其实是数据库服务端（如 MySQL、PostgreSQL）因超时策略强制踢掉的。你看到的“连接失效”，本质是客户端没做保活，服务端先放弃了。
MySQL 连接被 interactive_timeout 或 wait_timeout 终止
这是最常见的根源。MySQL 服务端默认设置 wait_timeout=28800（8 小时），interactive_timeout=28800；但很多生产环境会调低到 300–600 秒。DBeaver 空闲时不做任何操作，服务端等不到数据包，就直接关闭 TCP 连接。
- 错误信息典型表现为：
SQL错误[08S01]:从服务器成功接收到的最后一个数据包是120407毫秒前... - 不是 DBeaver 的 bug，而是服务端行为，客户端必须适配
- 不能靠“改服务端配置”来治本——DBA 通常拒绝调高 timeout，尤其在共享集群中
- 正确做法是让 DBeaver 主动发心跳，骗过服务端的空闲检测
在 DBeaver 中启用保活查询（keep-alive query）
DBeaver 不提供“自动断开”开关，但提供“防止断开”的保活机制。关键不是关连接，而是让连接看起来一直活跃。
- 右键数据库连接 → 编辑连接 → 切到 高级属性 标签页
- 找到
keep-alive query（保活查询），填入：SELECT 1 - 可选：同时设置
keep-alive interval（单位毫秒），例如30000（30 秒），避免太频繁加重服务端负担 - 保存后需重新连接才生效——旧连接不会自动加载新保活配置
- 注意：
SELECT 1对所有主流数据库都安全，但某些只读用户权限不足时可能报错，可换用DO 1（MySQL）或SELECT pg_sleep(0)（PostgreSQL）
connection keep-alive 和初始化设置里的“连接保持”不是一回事
很多人混淆两个地方：一个是“初始化”页签下的 connection keep-alive（单位秒），另一个是“高级属性”里的保活查询。前者仅控制 DBeaver 自身连接池内连接对象的复用时限，不影响网络层心跳；后者才是真正发 SQL 包维持 TCP 连接活跃的开关。
- “初始化”里的
connection keep-alive建议设为60，它影响的是 DBeaver 内部连接复用逻辑，和防断连关系不大 - 真正起作用的是“高级属性”中的
keep-alive query+keep-alive interval - 如果只改了初始化里的值但没配保活查询，连接照样会在几秒/几分钟后断开
- RisingWave、MariaDB、TiDB 等兼容 PostgreSQL 协议的数据库，同样适用这套保活逻辑
保活不是万能的——它不能绕过事务锁、连接池耗尽或网络中间设备（如 NAT 网关、防火墙）的 idle timeout。遇到反复断连，先确认是否真由数据库服务端超时引起，再检查网络链路是否稳定。最隐蔽的问题往往出在代理层，而非 DBeaver 本身。
