skuteczny sposób wdrożenia stronicowania

Spróbuj użyć

FROM [TableX]
ORDER BY [FieldX]
OFFSET 500 ROWS
FETCH NEXT 100 ROWS ONLY

Aby uzyskać wiersze od 501 do 600 W Sql serverze, bez ładowania ich do pamięci. Zwróć uwagę, że ta składnia stała się dostępna tylko w SQL Server 2012

Podczas gdy LINQ-to-SQL wygeneruje klauzulę OFFSET (ewentualnie emulowaną za pomocą ROW_NUMBER() OVER() jak inni wspominali ), istnieje zupełnie inny, znacznie szybszy sposób wykonywania stronicowania w SQL. Jest to często nazywane "seek method", jak opisano w ten wpis na blogu tutaj .

SELECT TOP 10 first_name, last_name, score
FROM players
WHERE (score < @previousScore)
   OR (score = @previousScore AND player_id < @previousPlayerId)
ORDER BY score DESC, player_id DESC

Wartości @previousScore i @previousPlayerId są odpowiednimi wartościami ostatniego rekordu z poprzedniej strony. Pozwala to na pobranie "następnej" strony. Jeśli kierunek ORDER BY wynosi ASC, po prostu użyj > zamiast tego.

Przy użyciu powyższej metody, nie można od razu przejść do strony 4 bez pobierania poprzednich 40 rekordów. Ale często i tak nie chcesz skakać tak daleko. Zamiast tego otrzymujesz znacznie szybsze zapytanie, które może być w stanie pobrać dane w stałym czasie, w zależności od indeksowania. Ponadto Twoje strony pozostają "stabilne", bez względu na to, czy Podstawowe Dane ulegną zmianie (np. na stronie 1, podczas gdy ty jesteś na stronie 4).

Jest to najlepszy sposób na zaimplementowanie stronicowania podczas leniwego ładowania więcej danych w aplikacjach internetowych, na przykład.

Uwaga, metoda "seek" jest również nazywana stronicowaniem keyset .

LinqToSql automatycznie skonwertuje a .Skip (N1).Weź(N2) do składni TSQL dla Ciebie. W rzeczywistości każde "zapytanie", które robisz w Linq, jest tak naprawdę tylko tworzeniem zapytania SQL dla Ciebie w tle. Aby to przetestować, po prostu uruchom SQL Profiler, gdy aplikacja jest uruchomiona.

Metodologia skip/take działa bardzo dobrze dla mnie, i innych z tego, co czytałem.

Z ciekawości, jaki masz rodzaj samo-stronicowania zapytań, który Twoim zdaniem jest bardziej wydajny niż Linq ' s skip / take?

Używamy CTE zawiniętego w dynamiczny SQL (ponieważ nasza aplikacja wymaga dynamicznego sortowania danych po stronie serwera) w ramach procedury składowanej. Mogę podać podstawowy przykład, jeśli chcesz.

Nie miałem okazji przyjrzeć się T/SQL, który tworzy LINQ. Czy ktoś może zamieścić próbkę?

Nie używamy LINQ ani prostego dostępu do tabel, ponieważ wymagamy dodatkowej warstwy bezpieczeństwa(z uwagi na dynamiczny SQL łamie to nieco).

exec sp_executesql 'WITH MyCTE AS (
    SELECT TOP (10) ROW_NUMBER () OVER ' + @SortingColumn + ' as RowID, Col1, Col2
    FROM MyTable
    WHERE Col4 = ''Something''
)
SELECT *
FROM MyCTE
WHERE RowID BETWEEN 10 and 20'

W SQL Server 2008:

DECLARE @PAGE INTEGER = 2
DECLARE @TAKE INTEGER = 50

SELECT [t1].*
FROM (
    SELECT ROW_NUMBER() OVER (ORDER BY [t0].[COLUMNORDER] DESC) AS [ROW_NUMBER], [t0].*
    FROM [dbo].[TABLA] AS [t0]
    WHERE ([t0].[COLUMNS_CONDITIONS] = 1)
    ) AS [t1]
WHERE [t1].[ROW_NUMBER] BETWEEN ((@PAGE*@TAKE) - (@TAKE-1)) AND (@PAGE*@TAKE)
ORDER BY [t1].[ROW_NUMBER]

W t0 są wszystkie rekordy W t1 są tylko te, które odpowiadają tej stronie

Można jeszcze poprawić wydajność, chech to

From CityEntities c
Inner Join dbo.MtCity t0 on c.CodCity = t0.CodCity
Where c.Row Between @p0 + 1 AND @p0 + @p1
Order By c.Row Asc

Jeśli użyjesz W ten sposób from, Da to lepszy wynik:

From   dbo.MtCity  t0
   Inner Join  CityEntities c on c.CodCity = t0.CodCity

Powód: ponieważ używasz klasy where w tabeli City, która wyeliminuje wiele rekordów przed przystąpieniem do MtCity, więc na 100% pewno zwiększy to wydajność wielokrotnie...

W każdym razie odpowiedź rodrigoelpa jest naprawdę pomocna.

Dzięki

Możesz zaimplementować stronicowanie w ten prosty sposób, przekazując PageIndex

Declare @PageIndex INT = 1
Declare  @PageSize INT = 20

Select ROW_NUMBER() OVER ( ORDER BY Products.Name ASC )  AS RowNumber,
    Products.ID,
    Products.Name
into #Result 
From Products

SELECT @RecordCount = COUNT(*) FROM #Results 

SELECT * 
FROM #Results
WHERE RowNumber
BETWEEN
    (@PageIndex -1) * @PageSize + 1 
    AND
    (((@PageIndex -1) * @PageSize + 1) + @PageSize) - 1

W 2008 roku nie możemy użyć Skip ().Take ()

Droga jest:

var MinPageRank = (PageNumber - 1) * NumInPage + 1
var MaxPageRank = PageNumber * NumInPage

var visit = Visita.FromSql($"SELECT * FROM (SELECT [RANK] = ROW_NUMBER() OVER (ORDER BY Hora DESC),* FROM Visita WHERE ) A WHERE A.[RANK] BETWEEN {MinPageRank} AND {MaxPageRank}").ToList();