JDBC连接超时由connectTimeout、socketTimeout和queryTimeout三层共同作用：connectTimeout控制TCP连接建立（毫秒），socketTimeout控制网络读写（毫秒），queryTimeout控制SQL执行（秒），三者缺一可能导致卡死或报错。
连接超时不是“设一个值就完事”，它由至少三层参数共同作用：JDBC驱动层的 connectTimeout、网络层的 socketTimeout、DBeaver UI 层的查询取消超时。漏配任何一层，都可能在特定场景下卡死或报错。
connectTimeout 和 socketTimeout 必须在连接高级参数里手动加
这两个参数默认不显示，也不会被自动继承。不手动添加，DBeaver 就用 JDBC 驱动的默认值（通常是 0，即无限等待），极易在弱网或数据库临时不可达时卡住界面。
-
connectTimeout=30000：TCP 连接建立上限 30 秒，适用于绝大多数生产环境 -
socketTimeout=60000：网络读写操作超时 60 秒；PostgreSQL 建议调高到120000，Oracle 可设180000 - 不要只填数字，必须带单位（毫秒），且不能有空格或引号
- ClickHouse 等列式库若走 HTTP 协议（如 8123 端口），
socketTimeout实际控制的是 HTTP 请求生命周期，建议不低于 120000
查询超时（queryTimeout）和 UI 取消超时是两回事
queryTimeout 是 JDBC 层向数据库发起的 SQL 执行级超时，由驱动传递给服务端；而 DBeaver 的「结果集取消超时」只是 UI 主动中断执行请求，不保证后端 SQL 真的停止。
- 在连接编辑页 → 高级 → 连接属性中添加
queryTimeout=300（单位：秒），这是真正让数据库终止慢查询的配置 - 全局 UI 取消超时在 首选项 > 数据库 > 结果集 > 查询取消超时 中设置，单位是毫秒，推荐填
300000（5 分钟），避免误杀长耗时但合法的分析查询 - Hive 连接容易因 Thrift 超时失败，此时
queryTimeout必须配合 HiveServer2 的hive.server2.idle.session.timeout同步调整，否则 DBeaver 提前取消，后端 session 却还挂着
不同数据库的验证查询（validationQuery）不能乱抄
连接池健康检查依赖 validationQuery，填错会导致连接反复创建失败，日志里出现大量 Validation query failed。
- MySQL / PostgreSQL / SQL Server：用
SELECT 1即可 - Oracle：必须用
SELECT 1 FROM DUAL，少FROM DUAL就报 ORA-00942 - ClickHouse：可用
SELECT 1，但若启用了readonly模式，需改用SELECT 1 SETTINGS readonly=0 - 别把
validationQuery和testOnBorrow当成可选项——高并发标签页场景下，不启用会导致大量 stale connection
最容易被忽略的是：DBeaver 的连接池空闲回收机制（idleTimeout）和数据库自身的 wait_timeout 不同步。比如 MySQL 设了 wait_timeout=600（10 分钟），但 DBeaver 的 idleTimeout 设成 1200 秒（20 分钟），空闲连接就会在数据库侧被悄悄断开，下次借用时抛出 Connection reset。务必让前者 ≤ 后者。
