MySQL的wait_timeout参数对应SQL Server的等效配置是什么

核心结论 #

SQL Server 本身没有和 MySQL wait_timeout 完全对等的原生服务端全局配置项，默认设计逻辑是将连接生命周期管理交由客户端连接池实现。
需注意经常被误认的 remote query timeout 配置，本质是控制跨实例远程查询的最大执行时长，和空闲连接回收无关，不要和MySQL wait_timeout 功能混淆。
你在Azure门户找不到对应配置是正常现象，Azure SQL 系列产品也未提供原生的全局空闲连接超时配置入口。

可用实现方案 #

• 【自建/托管实例通用：服务端定时回收】
  通过定时作业扫描空闲会话并主动销毁，是最贴近 wait_timeout 效果的实现方案，示例脚本如下（以空闲30分钟超时为例）：

  DECLARE @idle_timeout_min INT = 30
  DECLARE @kill_sql NVARCHAR(MAX) = N''
  
  -- 筛选符合条件的用户空闲会话
  SELECT @kill_sql += N'KILL ' + CAST(session_id AS NVARCHAR(10)) + N'; '
  FROM sys.dm_exec_sessions
  WHERE is_user_process = 1 -- 仅筛选用户会话，排除系统进程
    AND status = 'sleeping' -- 空闲状态
    AND DATEDIFF(MINUTE, last_request_end_time, GETDATE()) > @idle_timeout_min
    AND session_id <> @@SPID -- 排除当前执行脚本的会话
    -- 可额外添加过滤条件，排除需要保留的运维会话/业务长连接会话
  
  -- 执行销毁操作
  IF LEN(@kill_sql) > 0
  BEGIN
    EXEC sp_executesql @kill_sql
  END
  

  自建实例可以把上述脚本配置到 SQL Server 代理作业中，按固定间隔（比如每5分钟）执行；Azure SQL 实例可以搭配 Azure 自动化账户、定时 Azure Functions 执行脚本。

• 【推荐方案：客户端连接池配置】
  符合 SQL Server 设计逻辑的最优方案，各大语言的 SQL Server 驱动都支持连接池空闲回收配置：

  • .NET SqlClient 可在连接字符串配置 Connection Lifetime、Max Idle Time 参数
  • JDBC 驱动可配置 timeBetweenEvictionRunsMillis、minEvictableIdleTimeMillis 参数
  • ODBC 驱动可配置 Connection Pool Idle Timeout 参数
    客户端主动回收空闲连接不会出现服务端强制断开导致的客户端运行时异常，稳定性更高。

注意事项 #

• 服务端主动杀会话前请先在测试环境验证过滤规则，避免误杀正在执行长事务的会话，导致业务数据异常
• 生产环境优先使用客户端连接池配置方案，服务端定时回收仅作为连接泄漏场景的兜底手段

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