DBeaver查询被取消主因是result_set_cancel_timeout设置过小，默认30秒，建议调至300秒（5分钟）并重启生效；该设置仅作用于UI层，不影响JDBC底层超时。
查询被取消，不是SQL写错了，也不是数据库挂了，而是DBeaver主动中止了执行——它等不及了。
查一下 result_set_cancel_timeout 设置是否太小
DBeaver 在 UI 层有个硬性等待上限，超时就直接 cancel 查询，不跟数据库商量。这个值默认是 30 秒（部分版本甚至更短），对复杂 JOIN 或未建索引的 WHERE 条件来说，根本不够用。
- 路径：菜单栏【窗口】→【首选项】→【数据库】→【结果集】→【自动取消查询前的等待时间】
- 建议调到
300（5 分钟）起步，临时跑报表可设为1800（30 分钟） - 改完必须重启 DBeaver 才生效——这个设置不热加载，改了不重启等于白改
- 注意：这只是 UI 层取消，不影响 JDBC 连接本身的 socket timeout 或 query timeout
确认是不是 show processlist 里真有卡住的线程
如果 UI 显示“查询已被取消”，但 show processlist 里还有一堆你自己的 Sleep 状态连接，且 Time 值持续上涨，说明连接没真正释放，只是 DBeaver 断开了前端控制权。
- 执行
show processlist，过滤你本机 IP 或用户名，看是否有大量Sleep线程 - 如果有，用
KILL [ID]干掉对应线程（比如KILL 36590983） - 别只 kill 当前查询线程，要 kill 掉所有空闲但未关闭的旧连接，否则下次照样堵
- 长期解法：在连接配置的【驱动属性】里加
wait_timeout=600和interactive_timeout=600，让服务端主动回收
检查 JDBC URL 里有没有漏掉 socketTimeout 或 queryTimeout
DBeaver 的 UI 超时只是第一道关，底层 JDBC 驱动还有自己的超时逻辑。MySQL 驱动默认不设 socketTimeout，但某些网络环境（如跳板机、K8s Service）会静默丢包，导致连接假死。
- 在连接编辑页 → 【驱动设置】→ 【连接属性】里手动添加键值对：
-
socketTimeout=30000（单位毫秒，建议 30 秒起） -
connectTimeout=10000（防止连不上时卡住太久） - PostgreSQL 用户加
socket_timeout=30（单位秒） - 这些参数优先级高于 UI 设置，一旦触发，报错会是
Communications link failure而非“查询已被取消”
临时表查不到却报“查询已被取消”的典型陷阱
你以为是超时，其实根本没走到执行那步——CREATE TEMPORARY TABLE 成功了，但第二条 SELECT 因权限不足或跨会话失败，DBeaver 尝试重试几次后直接弹“查询已被取消”，掩盖了真实错误。
- 先手动执行
SELECT * FROM temp_reports LIMIT 1，看是否报Table doesn't exist或权限拒绝 - 临时表只在当前会话可见，不要在另一个 SQL 编辑器标签页里查——那是新会话
- 确认用户有
CREATE TEMPORARY TABLES权限（MySQL）或TEMP权限（PostgreSQL） - 如果用的是 MySQL 8.0+，还要检查认证插件是否为
caching_sha2_password，老驱动不兼容会导致连接中途断开，表现类似超时
最常被忽略的一点：DBeaver 的“查询已被取消”提示本身不带上下文，它可能是 UI 超时、JDBC 超时、网络中断、权限失败、甚至驱动类加载失败的统一出口。得先看日志——~/.dbeaver4/.metadata/.log 里那一行带 cancel 或 timeout 的堆栈，才是真相入口。
