11 月 14 日，科技媒体 BornCity 报道，微软已承认：部分 Windows 系统安装 10 月 13 日发布的累积更新后，使用 SQL Server 的环境可能出现数据库连接无法正常关闭的问题，而且 11 月的更新尚未修复它。
这不是小问题。对运维来说，”连接不关闭”意味着服务器会随着时间推移越来越慢，直到撑不住。
先说影响范围。微软承认的版本清单相当长：
Windows 11 26H1、25H2、24H2、23H2；
Windows 10 Enterprise LTSC 2019；
Windows Server 2025、2022、1809、2016、2012 R2、2012。
从客户端到服务器，从最新到十年前的老系统，几乎全线覆盖。这也解释了为什么这个问题的讨论度会这么高——它不是某个版本的偶发 bug，而是一次波及面很广的回归。
问题出在哪里？在 SQL Server 的”链接服务器”功能上，也就是通过 SQL Server 查询其他数据库。受影响环境使用 OLE DB 组件连接外部数据库，已知涉及 Oracle 和 PostgreSQL。
正常逻辑是：查询结束后，相应连接按预期关闭。受此问题影响后，部分连接会继续保持打开状态。单次看没什么，但随着后续查询不断累积，连接池被占满、资源被耗光，服务器性能就会逐步下滑。
临时缓解手段有两个：一是手动关闭已确认的非活动连接，二是重启 SQL 服务。但两者都有代价——可能中断正在执行的查询或事务，而且运行一段时间后，异常仍可能再次出现。
给正在用 SQL Server 的团队一份自查清单：
第一，先确认你有没有用到链接服务器。如果业务里完全没有跨库查询，这个问题的实际影响基本为零。
第二，如果有，立刻建立连接数监控。查 sys.dm_exec_sessions 和 sys.dm_exec_connections，按 login_name 和 program_name 分组看会话数变化趋势，比总连接数更有意义。
第三，看增长曲线而不是绝对值。连接泄漏的特征是”缓慢但持续上涨，且不随业务低峰回落”。如果你们的连接数在工作日凌晨还在爬坡，那基本可以确认。
第四，评估回滚成本。微软还没给出修复补丁，如果业务对性能敏感，可以考虑卸载 10 月 13 日那个累积更新——但要先确认这个更新有没有带别的安全修复，别为了性能把安全丢了。
第五，设置一个自动巡检。写个定时任务，每 10 分钟抓一次非活动会话数，超过阈值就告警。这类问题最怕的是没人发现，等业务方投诉才知道，那时候已经在丢单了。
最后说一个判断。微软承认了问题但一个月没修，说明修复本身不简单——涉及 OLE DB 组件和链接服务器的交互，改动可能牵一发动全身。对运维来说，这意味着不能等，得先自己上监控。
一句话：这不是”会不会影响你”的问题，而是”你的监控能不能提前发现它”的问题。
暂无评论内容