使用order by时，SQL Server连接查询速度很慢

Question

我们的数据库中有2个表。

1. U_Accounts（包含行的小表）
2. SMS_Buffer（包含短信排队的大表）

以下是示例查询

Select SMS_Buffer.msg_id, 
       SMS_Buffer.u_id, 
       SMS_Buffer.msgtxt, 
       SMS_Buffer.m_priority, 
       U_Accounts.U_Priority 
From SMS_Buffer
JOIN U_Accounts ON Sms_Buffer.u_id = U_Accounts.u_id 
where U_Accounts.u_msgpush=1 
Order by U_Accounts.u_priority DESC, 
         SMS_Buffer.m_priority DESC, 
         SMS_Buffer.m_id DESC

当ORDER BY子句与SMS_Buffer.m_priority DESC, SMS_Buffer.m_id DESC对SMS_Buffer表中少于100000行的记录使用{{1}}子句时，上面的查询会变慢。但是当它增长时，查询变得非常慢。

请求您为我们提供解决方案，以便更好地执行上述查询。

我们尝试过创建聚簇的非聚集索引，但没有取得任何成功。

Answer 1

如果没有关于索引和理想情况下执行计划的进一步信息，这是无法正确回答的，但是您看到的行为，即行数相对较少的快速查询，当达到某个卷时，性能会迅速恶化，通常表示使用全表扫描的查询，当表适合内存时这不是太糟糕但是当它变得如此之大以至于数据被写入磁盘时灾难性地恶化（磁盘I / O比操作中的操作慢几个数量级）记忆，所以你点击它通常是显而易见的。）

解决这个问题的唯一方法是检查执行计划并确定导致完整扫描的原因，但如果没有这些重要信息，那么您正试图解决这个问题。

Answer 2

当我遇到同样的事情时，来自this question的弗莱的答案有所帮助。简而言之，更新统计可能是解决方案。在SQL EXEC sp_updatestats 。

中

我正在处理2个子查询和一个表，然后进行排序。 3个结果集不到5000行，添加Order By将从12秒到5分钟。这太慢了。更新统计数据后，它会在1秒后运行。