В базе MSSQL 2005 таблица с 100000000 записей. Необходимо постранично получать данные.
Пробовал реализовать с использование функции ROW_NUMBER():

WITH OrderedObjects as (SELECT field1, field2, ROW_NUMBER() OVER (ORDER BY field1) AS RowNum FROM Table1)
SELECT OrderedObjects.* FROM OrderedObjects WHERE RowNum BETWEEN 10 AND 20

Такой вариант решения имеет существенный недостаток:

т.к. результирующие записи выбираются путем проверки (RowNum BETWEEN 10 AND 20) для каждой записи первого запроса,
то время выполнения будет расти вместе с индексом страницы.

Варианты решения с использованием временных таблиц и курсоров так же будут тормозить при выборе данных с большим индексом страницы.

Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?

Здравствуйте, ePilgrim, Вы писали:

P>В базе MSSQL 2005 таблица с 100000000 записей. Необходимо постранично получать данные.
P>Пробовал реализовать с использование функции ROW_NUMBER():

на мой взгляд постраничный вывод таких записей непрактичен, бо даже по 100 записей мы получаем 1 000 000 страниц...

Может стоит ввести категоризацию — и фильтровать по категориям?
Или хранить номер страницы в базе если сортинг не нужен?

Здравствуйте, ePilgrim, Вы писали:

P>Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?

Тут

Автор(ы): Иван Бодягин
Дата: 07.02.2004
Уникальная идентификация записей в таблице, является практически основой реляционных СУБД. Вообще в реляционной теории предполагается, что если две записи ни чем друг от друга не отличаются, то это явная избыточность, и количество таких записей можно сократить до одной. Собственно вопросам этой самой идентификации, каковых возникает на удивление много, и посвящен этот FAQ.

есть кое-что.

Здравствуйте, ePilgrim, Вы писали:

P>т.к. результирующие записи выбираются путем проверки (RowNum BETWEEN 10 AND 20) для каждой записи первого запроса,
P>то время выполнения будет расти вместе с индексом страницы.
Не должно, к тому же дальше третьей страницы обычно не ходят.

P>Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?
Можно еще вставить TOP в первую выборку.
Но вообще, если внимательно посмотреть на план запроса, то станет понятно, что это вообще самый оптимальный способ обеспечить постраничную выборку. Больше оптимизаций уже не навернешь, ни в сиквеле, ни где-либо еще.

Здравствуйте, B0rG, Вы писали:

BG>Может стоит ввести категоризацию — и фильтровать по категориям?

скорее всего это наиболее подходящий вариант. просто постраничный вывод не сильно эффективен на большом кол-ве записей.

BG>Или хранить номер страницы в базе если сортинг не нужен?

сортинг нужен. поэтому такой вариант отпадает.

Здравствуйте, wildwind, Вы писали:

P>>Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?

W>Тут

Автор(ы): Иван Бодягин
Дата: 07.02.2004
Уникальная идентификация записей в таблице, является практически основой реляционных СУБД. Вообще в реляционной теории предполагается, что если две записи ни чем друг от друга не отличаются, то это явная избыточность, и количество таких записей можно сократить до одной. Собственно вопросам этой самой идентификации, каковых возникает на удивление много, и посвящен этот FAQ.

есть кое-что.


полезная информация. спасибо за ссылку

Здравствуйте, IB, Вы писали:

P>>Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?
IB>Можно еще вставить TOP в первую выборку.
IB>Но вообще, если внимательно посмотреть на план запроса, то станет понятно, что это вообще самый оптимальный способ обеспечить постраничную выборку. Больше оптимизаций уже не навернешь, ни в сиквеле, ни где-либо еще.

использование TOP в первой выборке, как и дополнительная фильтрация по категориям преследует цель минимизации начального объема записей.
я Вас правильно понял?

P>Существует ли какой-то более оптимальный способ для постраничного выбора данных на MSSQL 2005?

Если есть возможность, то проще постранично брать на этапе фетчинга, тогда таких проблем не будет.

Здравствуйте, ePilgrim, Вы писали:

P>использование TOP в первой выборке, как и дополнительная фильтрация по категориям преследует цель минимизации начального объема записей.
P>я Вас правильно понял?
Да.