SQL Server查询优化器执行计划“语句提前终止的原因：超时”

Posted 2023-05-08

【中文标题】SQL Server查询优化器执行计划“语句提前终止的原因：超时”

【英文标题】：SQL Server Query Optimizer Execution Plan ""Reason for Early Termination of Statement: TimeOut"

【发布时间】：2013-11-08 22:08:46

【问题描述】：

环境： Windows 2008 R2、SQL Server 2008 SP1

问题： 9表的表内连接查询在实际执行计划中得到“提前终止语句的原因：超时”。

分配了错误的内存授予。

排序是在 tempdb 而不是 ram 中完成的，即使有大量可用的 ram。

在 tempdb 中进行排序时性能很慢。

考虑： 如果我从 9 个表之一中删除、创建和删除其中一个索引，则查询将再次得到全面优化，并且在 ram 中以完整的性能进行排序。但是，只要我稍微修改查询，它就会再次失去完整的优化。

问题： 有没有人见过这个问题？

有什么方法可以获取有关“超时”发生原因的更多信息吗？

优化器到底在做什么？

如果没有解决如何批准查询优化器问题的解决方案，我会考虑为 tempdb 制作一个 ramdisk。将 ramdisk 用于 tempdb 有哪些风险？

我已经尝试过的事情： 使用 FULLSCAN 更新 ALL 9 Tables 的统计数据

INDEX REBUILD 暂时像我上面所做的 DROP CREATE DROP 操作一样工作。

【问题讨论】：

如果您添加更详细的信息，例如实际查询计划本身，我们可以更好地回答这个问题。

【参考方案1】：

可能是您的索引变得支离破碎。如果您经常插入/删除/更新这 9 个表，就会发生这种情况。

重建索引示例：

ALTER INDEX MyIndex ON MyTable REBUILD

一段时间后，插入/删除/更新将再次分割您的索引。您可以安排重建以防止性能下降。例如参见：

http://technet.microsoft.com/en-us/library/ms180074(v=sql.100).aspx

【讨论】：

我实际上也做了索引重建。如果我保持查询相同，它会起作用，但只要我稍微更改查询就停止工作（比如更改 WHERE 子句中条件的顺序）。抱歉，我在原帖中放了更多信息。

【参考方案2】：

这是一篇讨论这个问题的文章：https://blogs.msdn.microsoft.com/psssql/2018/10/19/understanding-optimizer-timeout-and-how-complex-queries-can-be-affected-in-sql-server/

有什么症状？

以下是涉及的一些因素： 您有一个复杂的查询， 涉及大量连接表（例如，8 个或更多表是 加入）。

请注意，将大量表连接在一起意味着 SQL 需要考虑许多可能的连接顺序。

一种可能的解决方案是使用临时表分解为中间查询；另一种是自己确定最佳连接顺序并使用提示 FORCEORDER。