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

环境： Windows 2008 R2、SQL Server 2008 SP1

问题: 具有9个表的表内部联接查询在实际执行计划中获取“语句提前终止的原因：超时”

分配了错误的内存授予

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

在tempdb中进行排序时，性能较慢

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

问题: 以前有人见过这个问题吗

有没有办法获得更多关于“超时”发生原因的信息

优化器到底在做什么

如果没有解决方案如何批准查询优化器问题，我会考虑为TEMPDB做一个RAMDISK。将ramdisk用于tempdb有什么风险

我已经尝试过的事情： 使用FULLSCAN更新{ALL 9 Tables}上的统计信息

---

索引重建可以像我上面所做的删除-创建-删除操作一样临时工作。

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

重建索引的示例：

ALTER INDEX MyIndex ON MyTable REBUILD

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

---

以下是一篇讨论这一点的文章：

症状是什么

这里有一些涉及的因素：您有一个复杂的查询 涉及许多连接的表（例如，需要8个或更多的表） 加入）

注意，有许多表连接在一起意味着SQL有许多可能的连接顺序要考虑。p>

---

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

如果您添加更详细的信息，例如实际的查询计划本身，我们可以更好地回答这个问题。实际上，我也重建了索引。如果我保持查询不变，它就可以工作，但是只要我稍微更改一下查询（比如更改WHERE子句中条件的顺序），它就会停止工作。对不起，我在原来的帖子里放了更多的信息。