Golang操作Azure SQL数据库出现空闲连接超时与bad connection错误排查

故障触发链路完全匹配Azure SQL场景下的空闲死连接特征，你配置的10分钟空闲超时未生效，核心是三个逻辑错位：

• Go标准库database/sql的连接池超时清理是惰性触发，没有后台主动巡检逻辑。SetConnMaxIdleTime、SetConnMaxLifetime的判定动作，只会在连接从连接池被取出复用的那一刻执行。生产环境的中间网络节点（负载均衡、防火墙、NAT网关）空闲连接断连阈值通常在5-15分钟，远早于Azure SQL本身的30分钟空闲断连时间，会比你设置的10分钟清理逻辑更早把连接掐断。等你下次取连接的时候，这个连接早就成了死连接，根本等不到连接池的超时判定触发。
• 你的重试逻辑存在明显的错误判定漏项。长间隔请求时，你从连接池取出的连接早已被网络节点掐断，连接池本身感知不到连接状态，会直接把这个死连接返回给你。拿着死连接去启动事务的时候，首次操作就会抛出i/o timeout，但你在getConn、getTx两个函数的可重试错误列表里，都完全没有覆盖这类错误，直接把它判定为永久错误；同时坏连接没有被显式从连接池剔除，后续重试取出的还是同一个已经失效的连接，才会连续报bad connection直到最终失败。
• 低版本go-mssqldb本身缺少连接探活能力。早于v1.6.0的驱动版本，在从连接池取出连接时不会主动发送轻量探活请求，完全依赖业务层的错误反馈识别坏连接，进一步放大了死连接的影响范围。

• 补全错误识别逻辑：
  • 在getConn、getTx的可重试错误列表中，新增i/o timeout类错误的判定，不要把这类临时网络错误当成永久错误直接终止请求
  • 所有被识别为失效的连接，必须显式调用Close()方法永久剔除出连接池，绝对不能把已经报过连接错误的连接归还回池里，避免后续请求反复复用坏连接。
• 调整连接池参数匹配网络层阈值：
  • 将SetConnMaxIdleTime从10分钟下调到3分钟，比绝大多数云负载均衡、防火墙的5分钟空闲断连阈值更短，保证连接池会在网络设备主动掐断连接之前，提前清理掉闲置连接
  • 同步将SetConnMaxLifetime下调到5分钟，匹配Azure SQL的连接老化规则。
• 升级驱动版本：将go-mssqldb升级到v1.6.0以上版本，开启驱动内置的连接取出探活能力，提前识别已经失效的死连接。
• 补全事务重试的连接刷新逻辑：在getTx的重试流程中，遇到连接级错误时不要直接复用旧连接重试，要重新走getConn流程获取全新连接后再启动事务。

内容的提问来源于stack exchange，提问作者Woody1193