看起来你碰到了JDBC Bridge处理长耗时查询的典型超时问题，我之前帮朋友排查过几乎一模一样的情况，咱们一步步来拆解可能的原因和解决办法：

先确认下你的场景（避免我理解错）：你用的是ClickHouse v25.2.2.39，通过ClickHouse JDBC Bridge v2.1.0连接SQL Server，简单查询、甚至返回1万条结果的关联查询都能正常跑，但只要SQL Server端执行时间超过30秒的查询，就会触发VertxException: Connection was closed错误，对吧？

下面是几个优先级从高到低的排查方向：

• 先调JDBC Bridge本身的超时配置
  JDBC Bridge默认的连接空闲超时可能设得比较短（刚好30秒也说不定），你找到Bridge的配置文件application.conf，调整这两个关键参数：

  • vertx.http.client.idleTimeout：把它从默认的30秒改成你需要的时长，比如120s（根据你最长的查询耗时来定），这个参数是防止长时间没有数据交互的连接被判定为空闲而关闭
  • 另外检查下Bridge里对应SQL Server数据源的配置，有没有加queryTimeout属性，如果有类似queryTimeout=30的设置，直接删掉或者调大到合适值

• 检查SQL Server端的远程查询超时
  有时候SQL Server本身会限制远程查询的执行时间，你可以在SQL Server里执行这个命令看看当前配置：

  sp_configure 'remote query timeout'
  

  如果返回的config_value是30，那就是它在搞鬼，改成你需要的数值（比如300秒），然后执行RECONFIGURE让配置生效就行

• 调整ClickHouse端的等待超时
  ClickHouse在调用JDBC Bridge的时候，自身也有超时限制，你可以在执行长查询前临时调整参数，或者直接在jdbc()函数里指定：

  1. 临时设置ClickHouse的接收超时：

     SET receive_timeout = 300000; -- 单位是毫秒，这里是5分钟
     

     然后再执行你的长查询
  2. 或者在jdbc()函数里直接带超时设置：

     SELECT * FROM jdbc('DWH', '你的长查询语句', 'query_timeout=300000')
     

• 检查SQL Server JDBC驱动的超时参数
  如果你用的是微软官方的SQL Server JDBC驱动，可以在JDBC URL里加上这几个参数来避免超时：

  jdbc:sqlserver://你的SQLServer地址:1433;databaseName=DWH;loginTimeout=60;socketTimeout=300000;queryTimeout=0
  

  这里socketTimeout设成足够大的值（比如5分钟），queryTimeout=0表示不限制查询超时，交给SQL Server端来控制

你可以先从第一个调整JDBC Bridge的idleTimeout开始试，这个是最常见的触发30秒超时的原因，改完重启Bridge，跑个测试查询比如WAITFOR DELAY '00:00:35'; SELECT 1，看看还会不会报连接关闭的错误。

备注：内容来源于stack exchange，提问作者Stneick