DBeaver默认不启用自动重连，需为每个数据源单独在“连接恢复”标签页勾选“自动重连”，并设置重连间隔（5000–10000毫秒）和最大重连次数（5–10次），保存后须重启连接生效；测试连接成功不代表查询时不断连，还需同步配置connectTimeout、socketTimeout及connectionPool.maxIdleTime等毫秒级超时参数，并注意界面单位（秒）与驱动属性（毫秒）的差异。
DBeaver 默认不开启自动重连，断开后必须手动刷新或重连——除非你明确配置了重试参数和连接恢复策略。
怎么在连接配置里启用自动重连
自动重连不是全局开关，必须为每个数据源单独开启。关键操作在「连接恢复」标签页，不是「常规」或「驱动设置」里。
- 右键已有连接 → 编辑连接 → 切换到 连接恢复 标签页
- 勾选 自动重连（注意：这个选项默认是关闭的）
- 设置
重连尝试间隔（建议 5000–10000 毫秒，太短会压垮服务端） - 设置
最大重连次数（生产环境建议 5–10 次，避免无限轮询） - 保存后需重启该连接（关闭再打开），否则新配置不生效
为什么 test connection 成功但查询时仍频繁断连
测试连接只校验初始建连，不触发重连逻辑；真正暴露问题的是长空闲、网络抖动或服务端主动踢出连接。这时要同时检查三类超时：
-
connectTimeout（建连超时）：建议设为30000，防止卡在握手阶段 -
socketTimeout（读写超时）：建议设为60000，避免大结果集传输中断 -
connectionPool.maxIdleTime（空闲连接超时）：很多数据库（如 PostgreSQL、MySQL）服务端会 kill 空闲超过 5–10 分钟的连接，DBeaver 必须同步配置，否则池中连接已失效却还在复用
这些参数在连接配置的「驱动属性」或「高级设置」里添加，格式为键值对，例如：socketTimeout=60000。
HBase/Hive/DB2 等非标准 JDBC 数据源的重连限制
这类数据源依赖特定驱动实现重连逻辑，DBeaver 的通用重试机制可能被绕过或失效：
- HBase：官方驱动（
org.apache.hbase.thrift.ThriftClient或 Phoenix JDBC）不支持 socket 层自动重连，自动重连开关基本无效；实际依赖 ZooKeeper 故障转移能力，DBeaver 只能靠reconnect()方法触发重试，但失败后不会自动 fallback 到备用 ZK 节点 - Hive：Kerberos 认证场景下，TGT 过期会导致重连失败，即使配置了重试次数，也会卡在
loginTimeout阶段并抛出GSSException - DB2：需确认驱动版本是否支持
enableClientAffinitiesReconnect=true参数，老版本驱动（v10.5 以前）对连接中断无感知
连接池空闲超时与 keep-alive 冲突怎么办
DBeaver 的「连接保持」（Keep Alive）功能本质是发心跳 SQL（如 SELECT 1），但它和连接池的 maxIdleTime 是两套机制，容易互相干扰：
- 如果
maxIdleTime=300000（5 分钟），但连接保持设为 60 秒，DBeaver 会在连接空闲 60 秒后发心跳，但连接池可能已在 5 分钟后销毁该连接——导致心跳失败并报Connection closed - 正确做法：把
连接保持时间设为略小于maxIdleTime（例如 240 秒），并确保数据库服务端的wait_timeout/tcp_keepalive_time大于该值 - PostgreSQL 用户额外注意：
keepAlive参数在 JDBC URL 中需显式开启：jdbc:postgresql://host/db?keepAlive=true
最易被忽略的一点：所有超时单位都是毫秒，但 DBeaver 界面里「连接保持」输入框标的是“秒”，而「驱动属性」里必须填纯数字毫秒值——混用会导致重连行为完全失控。
