Позвольте SQL Server Query выполнить разбиение на страницы за вас (предложение OFFSET FETCH в SQL 2012)

Если вы занимались веб-программированием или каким-либо подобным сценарием, для которого необходимо читать данные из базы данных частями по соображениям производительности, вы определенно сталкивались с реализацией разбивки на страницы для выборки данных из базы данных постранично.

После введения функции ROW_NUMBER () SQL Server я использовал для этого, используя это, с добавлением предложений where для столбца ROW_NUMBER, чтобы пропустить определенное количество идентификаторов и ВЗЯТЬ определенное количество строк, которые я хочу вот так:

SELECT ROW_NUMBER() OVER( ORDER BY AgreementNUmber) , * FROM [Agreement] ORDER BY [AgreementNumber] OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY;

Или иногда я открываю все представление или таблицу, а затем в приложении я использую команды SKIP и TAKE C # LINQ для реализации разбивки на страницы, как это в C #:

var myPage = AgreementList.Skip(10).Take(5);

но теперь я вижу, что SQL SERVER 2012 представил эти команды OFFSET FETCH, с которыми вы можете сделать это намного проще.

Вот как это сделать:

SELECT * FROM [Agreement] ORDER BY [AgreementNumber] OFFSET 10 ROWS FETCH NEXT 50 ROWS ONLY;

Как вы можете легко догадаться, номер 10 - это номер ПРОПУСКА, а номер 5 - это номер ВЗЯТЬ или РАЗМЕР СТРАНИЦЫ.

А потом я сделал простой SQL STATISTICS VIEW, чтобы увидеть, какой из них лучше с точки зрения производительности, и обнаружил, что OFFSET FETCH в два раза быстрее, чем ROW_NUMBER!

Я попробовал тот же запрос на таблице с 10 000 строками, и у меня было такое время выполнения сервера sql! но все же это может быть разным в разных наборах данных

Время выполнения SQL Server: (с ROW_NUMBER ())
Процессорное время = 31 мс, затраченное время = 28 мс.
Время выполнения SQL Server: (с OFFSET и FETCH)
Процессорное время = 16 мс, прошедшее время = 15 мс.

Поэтому я действительно думаю, что мне следует просмотреть свои существующие коды разбивки на страницы и попытаться заменить их этим новым, если это возможно, поскольку это намного проще реализовать и намного быстрее (по крайней мере, с этим набором данных, с которым я тестировал)