Esiste un problema di prestazioni che utilizza Row_Number per implementare il paging delle tabelle in Sql Server 2008?

Question

Voglio realizzare tavolo paginazione con questo metodo:

SET @PageNum = 2; 
SET @PageSize = 10; 

WITH OrdersRN AS 
(
    SELECT ROW_NUMBER() OVER(ORDER BY OrderDate, OrderID) AS RowNum 
      ,* 
     FROM dbo.Orders 
) 

SELECT * 
    FROM OrdersRN 
WHERE RowNum BETWEEN (@PageNum - 1) * @PageSize + 1 
        AND @PageNum * @PageSize 
ORDER BY OrderDate ,OrderID; 

C'è qualcosa che dovrei essere a conoscenza? La tabella ha milioni di record.

Thx.

EDIT: Dopo aver utilizzato suggerito MAXROWS metodo per un certo tempo (che funziona davvero molto veloce) ho dovuto tornare alla ROW_NUMBER metodo a causa della sua maggiore flessibilità. Sono anche molto contento della sua velocità fino ad ora (sto lavorando con View con più di 1 milione di record con 10 colonne). Per utilizzare qualsiasi tipo di domanda che uso seguente modifica:

PROCEDURE [dbo].[PageSelect] 
(
    @Sql nvarchar(512), 
    @OrderBy nvarchar(128) = 'Id', 
    @PageNum int = 1, 
    @PageSize int = 0  
) 
AS 
BEGIN 
SET NOCOUNT ON 

Declare @tsql as nvarchar(1024) 
Declare @i int, @j int 

if (@PageSize <= 0) OR (@PageSize > 10000) 
    SET @PageSize = 10000 -- never return more then 10K records 

SET @i = (@PageNum - 1) * @PageSize + 1 
SET @j = @PageNum * @PageSize 

SET @tsql = 
'WITH MyTableOrViewRN AS 
(
    SELECT ROW_NUMBER() OVER(ORDER BY ' + @OrderBy + ') AS RowNum 
    ,* 
    FROM MyTableOrView 
    WHERE ' + @Sql + ' 

) 
SELECT * 
    FROM MyTableOrViewRN 
    WHERE RowNum BETWEEN ' + CAST(@i as varchar) + ' AND ' + cast(@j as varchar) 

exec(@tsql) 
END 

Se si utilizza questa procedura assicurarsi u impedito sql injection.

Answer 1

Ho scritto su questo un paio di volte in realtà; ROW_NUMBER è di gran lunga il più flessibile e facile da usare, e le prestazioni sono buone, ma per i set di dati estremamente grandi non è sempre il migliore. SQL Server ha ancora bisogno di ordinare i dati e l'ordinamento può diventare piuttosto costoso.

C'è un different approach here che utilizza un paio di variabili e SET ROWCOUNT ed è estremamente veloce, purché si abbiano gli indici corretti. È vecchio, ma per quanto ne so, è ancora il più efficiente. Fondamentalmente puoi fare un ingenuo con SET ROWCOUNT e SQL Server è in grado di ottimizzare la maggior parte del lavoro reale; il piano e il costo si rivelano simili a due query MAX/MIN, che di solito sono molto più veloci di una sola query con finestre. Per insiemi di dati molto grandi, questo funziona in meno di 1/10 di tempo.

Detto questo, raccomando sempre ROW_NUMBER quando le persone chiedono come implementare cose come paging o groupwise massimi, a causa di quanto sia facile da usare. Vorrei solo iniziare a guardare le alternative come sopra se inizi a notare rallentamenti con ROW_NUMBER.

Answer 2

Recentemente, ho utilizzato il paging in un ambiente di data warehouse con uno schema a stella. Ho scoperto che le prestazioni erano molto buone quando ho limitato il CTE per interrogare solo le righe necessarie per determinare lo ROW_NUMBER. Ho avuto il CTE restituire il ROW_NUMBER più le chiavi primarie delle altre righe che hanno contribuito a determinare il numero di riga.

Nella query principale, ho fatto riferimento allo ROW_NUMBER per il paging e quindi unito alle altre tabelle in base alle altre chiavi primarie del CTE. Ho scoperto che i join venivano eseguiti solo sulle righe che soddisfacevano la clausola WHERE nella query esterna, risparmiando molto tempo.

Answer 3

testare questa soluzione, forse è meglio. cambia questo con il tuo bisogno per favore.

CREATE PROCEDURE sp_PagedItems 
    (
    @Page int, 
    @RecsPerPage int 
    ) 
AS 

-- We don't want to return the # of rows inserted 
-- into our temporary table, so turn NOCOUNT ON 
SET NOCOUNT ON 


--Create a temporary table 
CREATE TABLE #TempItems 
(
    ID int IDENTITY, 
    Name varchar(50), 
    Price currency 
) 


-- Insert the rows from tblItems into the temp. table 
INSERT INTO #TempItems (Name, Price) 
SELECT Name,Price FROM tblItem ORDER BY Price 

-- Find out the first and last record we want 
DECLARE @FirstRec int, @LastRec int 
SELECT @FirstRec = (@Page - 1) * @RecsPerPage 
SELECT @LastRec = (@Page * @RecsPerPage + 1) 

-- Now, return the set of paged records, plus, an indiciation of we 
-- have more records or not! 
SELECT *, 
     MoreRecords = 
    (
    SELECT COUNT(*) 
    FROM #TempItems TI 
    WHERE TI.ID >= @LastRec 
    ) 
FROM #TempItems 
WHERE ID > @FirstRec AND ID < @LastRec 


-- Turn NOCOUNT back OFF 
SET NOCOUNT OFF