DBeaver 报 Broken pipe 主因是 MySQL 服务端空闲超时（默认8小时）主动断连，而 DBeaver 复用已失效连接发请求；需在 JDBC 驱动配置 testOnBorrow=true 和 validationQuery=SELECT 1 实现连接有效性校验。
直接说结论：DBeaver 报 Broken pipe，90% 是 MySQL 服务端主动断开了空闲连接，而 DBeaver 还拿着旧连接继续发查询；不是 DBeaver 本身有 bug，也不是你连错了库，而是连接池（或驱动层）没做有效性校验。
为什么 DBeaver 会突然报 Broken pipe？
MySQL 默认 wait_timeout = 28800（8 小时），空闲连接超时后服务端会直接 KILL 掉它。DBeaver 的 JDBC 连接默认不开启探活机制，一旦你隔了几小时再点“执行”，它就拿一个已关闭的 socket 去发 SELECT，内核返回 EPIPE，JDBC 驱动抛出 Broken pipe。
常见触发场景：
- 你打开 DBeaver 后放着不动，下班前执行了一条语句，第二天早上回来点“刷新表”就崩
- 连接树里右键某张表 → “查看数据”，但连接其实已在后台静默断开
- 使用 SSH 隧道或代理访问远程 MySQL，中间网络设备（如防火墙）设置了更短的 idle timeout
在 DBeaver 中启用 connection validation（推荐）
DBeaver 本身不管理连接池，但它复用 JDBC 驱动的连接配置。关键是在编辑连接时手动加验证参数：
- 右键连接 → Edit Connection → 切到 Driver Properties 标签页
- 找到或新增属性：
jdbcCompliant设为false（确保驱动走标准路径） - 新增属性：
autoReconnect设为true（老版本驱动可用，但不如下面两个可靠） -
最关键一行：新增属性：
testOnBorrow设为true，再加validationQuery=SELECT 1 - 如果用的是 MySQL 8.0+ 和 Connector/J 8.0.23+，可直接设
enabledTLSProtocols=TLSv1.2避免握手失败伪装成 Broken pipe
保存后重连——下次空闲后首次查询会先跑 SELECT 1，失败则自动重建连接，不再报错。
改 MySQL 服务端 wait_timeout 不现实？那就调客户端超时
如果你没有权限改 MySQL 的 wait_timeout（比如用的是云数据库 RDS），就得让 DBeaver 主动“放弃”快过期的连接：
- 在同个 Driver Properties 页，加参数：
socketTimeout=30000（单位毫秒，5 秒读超时，防卡死） - 加参数：
connectTimeout=5000（连接建立超时） - 加参数：
maxReconnects=2+initialTimeout=1（配合autoReconnect=true实现有限重试） - 注意：
wait_timeout是服务端值，socketTimeout是客户端值，二者不等价，别混淆
这些参数不会阻止断连，但能让 DBeaver 在断连后更快失败、更快重建，而不是卡住或抛奇怪错误。
容易被忽略的三个细节
真正线上踩过坑的人才会注意：
- DBeaver 的“SQL 编辑器”和“元数据浏览”（比如点开表结构）走的是不同连接路径，后者可能绕过你配的
validationQuery，建议统一勾选连接设置里的 “Connect on every operation”（开发调试时开，生产慎用） - 如果你用的是 SSH 隧道，
Broken pipe更可能是隧道进程（如ssh -L）自己挂了，而非 MySQL 断连——此时要检查本地ssh进程是否存活 - 某些企业网络出口有 DPI 设备，会静默 kill 长连接，且不发 RST；这种情况下
SELECT 1也会超时，得换用validationQueryTimeout=2缩短探测时间
归根结底，Broken pipe 不是故障，是 TCP 连接生命周期的正常终点。你不需要消灭它，只需要让 DBeaver 在它发生前就感知并换新连接。
