【发布时间】：2015-04-30 17:05:24
【问题描述】：
我在 SQL Server 2005 中遇到了一个非常奇怪的问题。
昨天用户报告我们的数据库应用程序的特定部分运行缓慢。我不确定缓慢是多么普遍——它肯定不是无处不在，因为这是系统报告的唯一部分——但我隔离了相关的存储过程，它曾经在 2-3 秒内运行，现在一直运行在 50- 60 秒。
这是一个复杂的查询——多层子查询。它仅返回 16 列中的 42 行。
查询如下所示：
select col1,2,3,4,5,...
from
( select .... ) t
ORDER BY col1
我开始分解查询以找出缓慢的原因，并发现删除最后的ORDER BY 子句使性能恢复正常。
这是非常神秘的。我无法在我们的 DEV 服务器上复制该问题。它只有 42 行，所以 order by 子句应该是无关紧要的。执行计划在两台服务器上是相同的，但没有顺序。
任何关于我们的生产服务器可能发生变化的头脑风暴将不胜感激！
【问题讨论】：
-
任何数量的东西，但如果它只是这一个查询，它可能是未完成的写锁 - 除非您指定 (nolock)，否则查询将使用读锁，这不一定是一件好事。它也可能是其中一张表上的索引碎片。
-
你有执行计划前后对比吗？您是否至少有一个执行后的计划可以查看？
-
在 prod 现在，执行计划在有和没有 order by 的版本之间是相同的，只是为 order by 版本添加了最后一个排序运算符。我在 DEV 上生成了一个执行计划，没有出现问题，而且它也是相同的。
-
是的，您可以尝试重建索引。
-
我会试一试，谢谢！
标签： sql-server stored-procedures sql-server-2005 sqlperformance