使用订单时，SQL Server连接查询速度慢

U_Accounts（含小表行）
SMS_Buffer（大表含短信队列）

下面是一个简单的查询，当我们使用ORDER BY

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

上面的查询变得缓慢子句SMS_Buffer.m_priority DESC, SMS_Buffer.m_id DESC对于记录小于100000行的SMS_Buffer表，但w当它增长查询变得非常缓慢。

请您向我们提供的解决方案为上述查询的性能更好。

我们试图创建聚簇，非聚集索引，但并未有任何的成功。

来源

2012-02-14 user1209658

请格式化你的代码接下来的时间，这是非常难以阅读文本 – Blorgbeard 2012-02-14 17:57:19

你创造什么指标，什么是你的执行计划的墙？ – HLGEM 2012-02-14 18:11:10

并定义缓慢，你有什么键... – 2012-02-14 18:16:46

这不能没有进一步的信息，以索引和理想的执行计划适当回答的问题，但你看到的行为，从而以较少行的快速查询看到业绩迅速恶化，当它达到一定的量通常表示使用全表扫描的查询，当表适合内存时这并不算太坏，但当数据增长得如此之大以至于数据被写入磁盘时，它会发生灾难性的恶化（磁盘I/O比操作慢几个数量级在记忆中，所以你点击这个点通常是显而易见的）。

你唯一的解决这种方式是为了检查执行计划，并确定是什么原因造成的全面扫描，但没有那个必要的信息，你正在试图解决这个盲人。

来源

2012-02-14 21:24:32 Cruachan

你最好的办法是引用执行计划 - 这将是最好的 - [链接]（http://www.simple-talk.com/sql/performance/execution-plan-基本/） – Aklopper 2012-02-17 12:24:41

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

我正在处理2个子查询和一个表，然后排序。这3个结果集都在5,000行以下，添加Order By将从12秒到5分钟。这是非常缓慢的。更新统计数据后，它在1秒内运行。

来源

2014-05-02 18:26:18 isopropanol

使用订单时，SQL Server连接查询速度慢

回答

相关问题