SQL2008r2性能-对于较小的结果集（25行，20列），ORDER BY速度较慢

我有一个如下形式的查询：

SELECT [Col1], [Col2], ..., [ColX]
FROM ( *** VERY LARGE QUERY WITH LOTS OF JOINS ***) [Src]

现在，此查询几乎立即返回25行，但如果我最后附加ORDER BY，则它将挂起：

SELECT [Col1], [Col2], ..., [ColX]
FROM ( *** VERY LARGE QUERY WITH LOTS OF JOINS ***) [Src]
ORDER BY [Col1], [Col2], [Col3], [Col4]

如果我这样做，也会发生同样的情况：

SELECT * FROM (
SELECT [Col1], [Col2], ..., [ColX]
FROM ( *** VERY LARGE QUERY WITH LOTS OF JOINS ***) [Src]) [Src]
ORDER BY [Col1], [Col2], [Col3], [Col4]

但是，如果我立即执行，查询几乎会执行：

SELECT * INTO #TempTable FROM (
SELECT [Col1], [Col2], ..., [ColX]
FROM ( *** VERY LARGE QUERY WITH LOTS OF JOINS ***) [Src]) [Src]

SELECT * FROM #TempTable
ORDER BY [Col1], [Col2], [Col3], [Col4]

---

我检查了执行计划，它显然试图在查询深处的一个源表上执行索引查找和键查找。因为orderby应该只关注这25行，所以我不明白为什么它会关注父表的索引。有什么想法吗？

聚集索引将大大加快查询顺序。是的，但这没有意义，因为它只是对输出进行排序。查询计划中是否存在预期行数与实际行数严重不匹配的地方？如果是这样的话，你能更新统计信息来修复它吗？Update StestDISTICS确实作为一个带帮助修复，但是一旦表再次被更新，问题就会再次出现。你添加了很多关于为什么它会起作用的好信息。但引擎似乎没有做出一致的选择。这确实表明了维护索引方面的挑战。如果能看到这些变体周围的查询计划，那就太好了——尤其是当它在更新统计数据之后运行得很快，然后又运行得很慢的时候。然后检查碎片，我们可以说更多。