SQL存储过程由高行号

从很长的动态续集存储过程生成该查询的过滤时运行极慢 - 则过程返回以Telerik的radgrid控件要显示的开始的给定索引处记录的请求号码，有效处理分页。在存储过程的输出的简化版本：SQL存储过程由高行号

SELECT r.* FROM (
     SELECT ROW_NUMBER() OVER(ORDER BY InventoryId DESC) as row, 
     v.* FROM vInventorySearch v 
     ) as R WHERE [ROW] BETWEEN 1 AND 10

当“之间”子句是1和10之间，它在第二个的一部分运行，但如果它是像万和1010之间需要几乎完整分钟执行。

我觉得我可能失去了一些东西根本，但在我看来，这不应该的问题这10条记录，我检索，应采取相同的时间量。

感谢您的任何输入，我期待着成为尴尬！

解决方案，礼貌马丁·史密斯（如下图）：

SELECT r.*, inv.* FROM 
(
    SELECT ROW_NUMBER() OVER(ORDER BY InventoryId DESC) as row, v.InventoryID 
    FROM vInventorySearch v 
    WHERE 1=1 
) as R 
inner join vInventory inv on r.InventoryID = inv.InventoryID 
WHERE [ROW] BETWEEN 10001 AND 10010

感谢您的帮助！

来源

2012-11-02 Shmaniel

您可以发布您的表定义包括索引和执行计划？ –

分页通过ROW_NUMBER确实可以为更高的行数非常低效。

有时候最好稍微分解一下，并在窄索引上使用ROW_NUMBER查询来检索具有连接返回基表上的匹配PK以检索缺失的列。

来源

2012-11-02 20:04:52

非常感谢，马丁。这正是我最终做的事情......查询从45秒缩短到几分之一秒。解决方案在后。 – Shmaniel

@DanielMyManiel - 很高兴帮助。我已经看到了'ROW_NUMBER'计划，它在那里做了数千次不必要的书签查找，以检索从未实际最终获得使用的列值，因为它们只用于匹配过滤器的10行左右。我想你的情况'vInventorySearch'可能是一个视图，所以也许它正在执行一些更昂贵的东西。 –

+1学到了新东西。 – Kermit

SQL 2012具有更高效的分页机制

http://stevestedman.com/2012/04/tsql-2012-offset-and-fetch/

SELECT DepartmentID的，收入一年收入 ORDER BY年，DepartmentID的ASC OFFSET 10行FETCH NEXT 10行仅对;

来源

2012-11-02 21:04:42

谢谢你，我必须检查出来。现在我正在使用SQL 2008，但是会在下一个项目中记住这一点。 – Shmaniel

SQL存储过程由高行号

回答

相关问题