如何避免 Sql 查询超时答案

【问题标题】：How to avoid Sql Query Timeout如何避免 Sql 查询超时
【发布时间】：2009-05-12 16:30:04
【问题描述】：

我对 SQL 视图具有 RO 访问权限。下面的这个查询超时。如何避免这种情况？

select  
  count(distinct Status)  
from 
  [MyTable]  with (NOLOCK)
where 
  MemberType=6

我得到的错误信息是：

消息 121，级别 20，状态 0，行 0

从服务器接收结果时发生传输级错误（提供者：TCP Provider，错误：0 - 信号量超时期限已过。）

【问题讨论】：

多长时间后才会出现错误？
那是很长一段时间。您的示例中的 [MyTable] 是表还是视图？如果是视图，请发布视图定义，我们可以尝试并提出优化建议。
这是一个视图。不幸的是，我无权查看视图定义。
哎呀，这很棘手。也许 Cade Roux 的建议是最好的 - 请求 DBA 为视图编制索引。
每次需要15-20分钟？

标签： sql sql-server

【解决方案1】：

您的查询可能没问题。 “信号量超时期限已过”是网络错误，而不是 SQL Server 超时。

您和 SQL Server 之间显然存在某种网络问题。

编辑：但是，显然查询在给出网络错误之前运行了 15-20 分钟。那是一个很长的时间，所以可能网络错误可能与执行时间长有关。底层视图的优化可能会有所帮助。

如果您示例中的 [MyTable] 是一个视图，您能否发布视图定义以便我们进行优化？

【讨论】：

您答案中的链接已过期
@Archmede 谢谢，我删除了链接，因为它不重要

【解决方案2】：

虽然显然存在某种网络不稳定或某些东西干扰了您的连接（可能需要 15 分钟，您可能会越过 NAT 边界，或者您的网络中的某些东西正在丢弃会话），但我认为您想要这样一个简单的?) 查询以在任何预期的时间（如 1 秒）内很好地返回。

我会与您的 DBA 交谈，并在 MemberType、Status 的基础表上创建一个索引。如果没有单个基础表或者这些表更复杂并且由视图或 UDF 创建，并且您正在运行 SQL Server 2005 或更高版本，请让他考虑为视图编制索引（基本上以索引方式实现视图）。

【讨论】：

【解决方案3】：

这是因为另一个 sql server 实例正在运行。所以你需要先kill，然后才能登录SQL Server。

为此转到任务管理器并终止或结束 SQL Server 服务任务，然后转到 Services.msc 并启动 SQL Server 服务。

【讨论】：

【解决方案4】：

请检查您的 Windows 系统事件日志中是否有任何专门针对“事件源：Dhcp”的错误。这很可能是与 DHCP 相关的网络错误。地址租用时间到期左右。这不应该是与 SQL Server 或查询本身有关的问题。

只需在互联网上搜索“信号量超时期限已过”，您就会得到很多建议，这些建议可能会解决您的问题。不幸的是，似乎没有针对此问题的解决方案。

【讨论】：

我知道这是五年前的事了，但您为什么认为这是固定网络上的 DHCP 问题...？如果他正在运行数据库服务器，他可能有一个固定的地址方案。我觉得好像这是一个没有答案的答案。
（又过了五年。）这与 DHCP 有什么关系？即使有问题的机器通过 DHCP 获得 IP 地址，在几乎所有情况下，到期的租约都会使用相同的地址续订。如果您的客户端或服务器在进程中间更改 IP 地址，您将遇到很多其他问题。而且它不容易重现。

【解决方案5】：

您可以在 MemberType 上放置一个索引。

【讨论】：

RO 访问可能更成问题，但可以要求 DBA 将其添加到表中。

【解决方案6】：

您是否在 Status 列和 MemberType 列上定义了索引？

【讨论】：

【解决方案7】：

你有多少条记录？表上有索引吗？试试这个：

;with a as (
select distinct Status
from MyTable
where MemberType=6
)
select count(Status)
from a

【讨论】：

【解决方案8】：

我的团队在使用长时间运行的 SSIS 包时间歇性地遇到这些问题。自从 Windows 服务器修补以来，这种情况一直在发生。

我们的 SSIS 和 SQL 服务器位于不同的 VM 服务器上。

与我们的 Wintel 服务器团队合作，我们重新启动了两台服务器，目前问题似乎已经消失。

工程师说他们不确定问题是出在他们同时更新的补丁还是新的 VMTools 上。我们现在将进行监控，如果超时问题再次出现，他们将尝试回滚 VMXNET3 驱动程序，首先，如果这不起作用，请移除 June Rollup 补丁。

所以对我们而言，问题与我们的 SQL 查询无关（我们正在加载数十亿新行，因此它必须长时间运行）。

【讨论】：

【解决方案9】：

虽然我很想把问题归咎于我的问题 - 我的查询也遇到了同样的错误，这个错误要大得多并且涉及很多循环 - 在网络上，我认为情况并非如此。

不幸的是，事情没那么简单。查询在出现该错误之前运行了 3 个多小时，如果它只是 SSMS 中的一个查询和 SQL Server 上的一个作业，它显然会同时崩溃（还没有查看详细信息，所以不确定它是否是同一个错误；不过肯定是同一个地方）。

所以万一有人来这里遇到类似的问题，这个线程： https://www.sqlservercentral.com/Forums/569962/The-semaphore-timeout-period-has-expired

建议这同样可能是硬件问题或实际超时。

就每个循环所需的时间而言，我的循环并不均匀（它们取决于给定月份的销售水平），所以计算好的月份大约需要 20 分钟（查询看起来是 4 年）。

这样我完全有可能需要优化我的查询。我什至会说这很可能，因为我所做的一些更改包括新表，这些表是堆......所以在进入 VM 配置和硬件测试之前，又要对我的数据进行另一轮索引。

意识到这是个老问题：我使用的是 SQL Server 2012 SE，SSMS 是 2018 Beta 版，运行 SQL Server 的 VM 独占使用 132GB 内存（总共 30%）、8 个内核和 2TB SSD SAN。

【讨论】：