Question

更新：事实上保留以下复杂的查询，请检查此查询。它说Fetch是98％，而Row_Number是2％？

enter image description here

是否为sql server 2012提取了另一个营销关键字？

-------------------------原始问题--------------------

让我清楚一点，无论我在哪里阅读，我都会发现Fetch比旧的Row_Number函数快得多。但是，我发现它几乎与 long 方式相反。我的数据库有近20万条记录。这是我使用Fetch的查询：

exec sp_executesql N'set arithabort off;set transaction isolation level read uncommitted;
                                    Select cte.DocumentID, cte.IsReEfiled, cte.IGroupID, cte.ITypeID, cte.RecordingDateTime, cte.CreatedByAccountID, cte.JurisdictionID, 
                        cte.LastStatusChangedDateTime as LastStatusChangedDateTime
                        ,  cte.IDate, cte.InstrumentID, cte.DocumentStatusID,ig.Abbreviation as IGroupAbbreviation, u.Username, j.JDAbbreviation, inf.DocumentName,
                       it.Abbreviation, cte.DocumentDate, ds.Abbreviation as DocumentStatusAbbreviation,  ds.Name as DocumentStatusName,
                        ( SELECT CAST(CASE WHEN cte.DocumentID = (
                                SELECT TOP 1 doc.DocumentID
                                FROM  Documents doc
                                WHERE doc.JurisdictionID = cte.JurisdictionID
                                        AND doc.DocumentStatusID = cte.DocumentStatusID
                                ORDER BY LastStatusChangedDateTime) 
                            THEN 1
                            ELSE 0
                        END AS BIT)
                        ) AS CanChangeStatus ,

                        Upper((Select Top 1 Stuff( (Select ''='' + dbo.GetDocumentNameFromParamsWithPartyType(Business, FirstName, MiddleName, LastName, t.Abbreviation, NameTypeID, pt.Abbreviation, IsGrantor, IsGrantee)  From DocumentNames dn
                                Left Join Titles t
                                    on dn.TitleID = t.TitleID               
                                Left Join PartyTypes pt
                                    On pt.PartyTypeID = dn.PartyTypeID
                                        Where DocumentID = cte.DocumentID
                                            For XML PATH('''')),1,1,''''))) as FlatDocumentName 

                        FROM Documents cte Left Join DocumentStatuses ds On                     
                        cte.DocumentStatusID = ds.DocumentStatusID 
                        Inner Join Users u on cte.UserID = u.UserID
                        Inner Join IGroupes ig On ig.IGroupID = cte.IGroupID
                        Inner Join ITypes it On ig.IGroupID = it.IGroupID
                        Left Join InstrumentFiles inf On cte.DocumentID = inf.DocumentID 
                    Left Join Jurisdictions j on j.JurisdictionID = cte.JurisdictionID Where 1=1
                    Order by cte.LastStatusChangedDateTime OFFSET 110700 Rows FETCH Next 50 Rows ONLY',N'@0 int,@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 int,@8 int,@9 int,@10 int,@11 int',
                    @0=4,@1=1,@2=5,@3=9,@4=4,@5=1,@6=1,@7=5,@8=9,@9=4,@10=1,@11=1

上述查询需要17秒才能生成50条记录。这是查询计划：

enter image description here

如果图像不清楚，这是查询计划XML： https://www.dropbox.com/s/br5urj4xapazu9l/fetch.txt

现在这是使用旧Row_Number的相同查询（并使用相同的DB索引和列以及联接作为Fetch）：

exec sp_executesql N'set arithabort off;set transaction isolation level read uncommitted;With cte as (Select peta_rn = ROW_NUMBER() OVER (ORDER BY  d.LastStatusChangedDateTime  asc )  
                                                , d.DocumentID
                                                , u.Username
                                                , it.Abbreviation AS ITypeAbbreviation
                                                , ig.Abbreviation AS IGroupAbbreviation
                                                , d.IsReEfiled 
                                                , d.IGroupID 
                                                , d.ITypeID 
                                                , d.RecordingDateTime 
                                                , d.CreatedByAccountID 
                                                , d.JurisdictionID
                                                , d.LastStatusChangedDateTime AS LastStatusChangedDateTime 
                                                , d.IDate 
                                                , d.InstrumentID 
                                                , d.DocumentStatusID
                                                , d.DocumentDate
                                From Documents d
                                Inner Join Users u on d.UserID = u.UserID Inner Join IGroupes ig on ig.IGroupID = d.IGroupID
                                Inner Join ITypes it on it.ITypeID = d.ITypeID Where 1=1  ANd d.IGroupID = @0   And (d.JurisdictionID = @1 Or DocumentStatusID = @2 Or DocumentStatusID = @3
                                    Or DocumentStatusID = @4 Or DocumentStatusID = @5)   And d.DocumentStatusID <> 3 And  d.DocumentStatusID <> 8 And  d.DocumentStatusID <> 7 AND
                                        ((CreatedByJurisdictionID = @6 Or DocumentStatusID = @7 Or DocumentStatusID = @8
                                        Or DocumentStatusID = @9 Or DocumentStatusID = @10
                                    Or CreatedByAccountID IN (Select AccountID From AccountsJurisdictions Where JurisdictionID = @11)))) Select cte.DocumentID, cte.IsReEfiled, cte.IGroupID, cte.ITypeID, cte.RecordingDateTime, cte.CreatedByAccountID, cte.JurisdictionID, 
                        cte.LastStatusChangedDateTime as LastStatusChangedDateTime
                        ,  cte.IDate, cte.InstrumentID, cte.DocumentStatusID,cte.IGroupAbbreviation, cte.Username, j.JDAbbreviation, inf.DocumentName,
                       cte.ITypeAbbreviation, cte.DocumentDate, ds.Abbreviation as DocumentStatusAbbreviation,  ds.Name as DocumentStatusName,
                        ( SELECT CAST(CASE WHEN cte.DocumentID = (
                                SELECT TOP 1 doc.DocumentID
                                FROM  Documents doc
                                WHERE doc.JurisdictionID = cte.JurisdictionID
                                        AND doc.DocumentStatusID = cte.DocumentStatusID
                                ORDER BY LastStatusChangedDateTime) 
                            THEN 1
                            ELSE 0
                        END AS BIT)
                        ) AS CanChangeStatus ,

                        Upper((Select Top 1 Stuff( (Select ''='' + dbo.GetDocumentNameFromParamsWithPartyType(Business, FirstName, MiddleName, LastName, t.Abbreviation, NameTypeID, pt.Abbreviation, IsGrantor, IsGrantee)  From DocumentNames dn
                                Left Join Titles t
                                    on dn.TitleID = t.TitleID               
                                Left Join PartyTypes pt
                                    On pt.PartyTypeID = dn.PartyTypeID
                                        Where DocumentID = cte.DocumentID
                                            For XML PATH('''')),1,1,''''))) as FlatDocumentName 

                        FROM cte Left Join DocumentStatuses ds On
                        cte.DocumentStatusID = ds.DocumentStatusID Left Join InstrumentFiles inf On cte.DocumentID = inf.DocumentID 
                    Left Join Jurisdictions j on j.JurisdictionID = cte.JurisdictionID Where 1=1 And peta_rn>@12 AND peta_rn<=@13 Order by peta_rn',N'@0 int,@1 int,@2 int,@3 int,@4 int,@5 int,@6 int,@7 int,@8 int,@9 int,@10 int,@11 int,@12 int,@13 int',@0=4,@1=1,@2=5,@3=9,@4=4,@5=1,@6=1,@7=5,@8=9,@9=4,@10=1,@11=1,@12=110700,@13=110750

此查询不到1秒！这是查询计划： enter image description here

enter image description here

那么，我错过了什么？为什么row_number比Fetch快？

这是rownum的查询计划： https://www.dropbox.com/s/uin66esfb2ov8m7/rownum.txt

Answer 1

我认为您的问题不是OFFSET / FETCH与ROW_NUMBER

在原始问题中，两个查询不相同，

第一个查询（OFFSET / FETCH）错过了参数的所有过滤条件，因此它适用于更大的基础数据，并且通过许多JOIN，记录数量可以快速增长

在第二个查询（ROW_NUMBER）中，左边连接在CTE执行后应用，仅用于匹配记录（peta_rn＆gt; @ 12 AND peta_rn＆lt; = @ 13），减少了很多要加入的记录。

两个查询完全没有可比性，我认为如果你编写CTE版本，使用OFFSET / FETCH它会比ROW_NUMBER版本更快。

实际上在谈论你的 EDIT / UPDATE ，不要考虑执行计划告诉你的内容，只执行两者并测量时间。你会发现OFFSET / FETCH无论如何都更快。

2018-10-04编辑/更新
我在不同场景上做了一些测试，我发现结果可能会有所不同，具体取决于索引和表基数（又名COUNT(*)）

如果按照具有聚簇索引OFFSET/FETCH的列进行排序，则会比ROW_NUMBER快得多。在小表（少于20000行）上，执行时间几乎相同，但是大表OFFSET/FETCH将很快变得更快（200-300％）。

如果按照具有非聚集索引的列进行排序，OFFSET/FETCH永远不会比ROW_NUMBER差，但后者可以很好地执行，具体取决于参数（表行数，起始记录和行数）取出的）。

如果按照没有任何索引的列进行排序OFFSET/FETCH仍然比ROW_NUMBER快一点，但它们的表现几乎相同。

Answer 2

http://www.mssqltips.com/sqlservertip/2696/comparing-performance-for-different-sql-server-paging-methods/ 根据以上内容，Fetch最适合2012年...

Sql server 2012获取vs旧row_number性能。我错过了什么？为什么row_number快17倍？

2 个答案: