MS-SQL смещение n строк выборка следующих m строк только с фиктивным порядком по столбцам - согласованные результаты?

#sql-server

Вопрос:

предложение «Смещение n строк извлекает только m строк» работает только с указанным «порядком по», что, конечно, делает запрос медленнее, чем без порядка.

Мы с моим коллегой пытались упорядочить по константе:

 select 0 as SORT_DUMMY, p.* from table p order by 1 Offset 0 rows fetch next 10 only

однако команда выполняется без проблем — я не уверен, вернет ли это строки воспроизводимым образом (мы используем это для разбивки на страницы).

У кого-нибудь есть какие-либо идеи по этому поводу?

С уважением

Йоханнес Колмзее

1. используйте ORDER BY для столбца, который является детерминированным

2. итак, вы говорите, что это не будет воспроизводимо? (или, по крайней мере, небезопасно — следующая версия может взорваться?)…. также «выбрать p. * из таблицы p order по enumcolumn» (где значения enumcolumn будут разделены между строками) не будет воспроизводимым?

3. порядок по 1 отличается от порядка по столбцу, который является детерминированным, или набору столбцов, порядок которых будет уникальным.

Ответ №1:

Чтобы ответить на мой собственный вопрос….

Вы определенно должны сортировать по столбцам, которые дают уникальную сортировку.

Несколько причин (все подходят для MS-SQL, но должны применяться и ко всем другим DB, также были проведены положительные предварительные тесты на oracleas):

если вы этого не сделаете, база данных может (и, вероятно, будет в будущем с обновлением или для определенных выборок) возвращать строки в любом порядке, который она считает нужным, если вы не заставите ее. ОШИБКА
никаких ЗАТРАТ не требуется, потому что лучше всего просто использовать первичный ключ (ы) в качестве сортировки в их «естественном порядке сортировки» (в зависимости от того, что это, направление индекса определяет его)
иногда — неправильный фиктивный столбец приведет к УХУДШЕНИЮ времени запроса (поверьте мне, был там, сделал это) — вероятная причина в том, что «0 как фиктивный», очевидно, не имеет уникального индекса.
если вы сортируете по уникальным столбцам, вы можете использовать его для «постоянного времени запроса», независимо от того, выбираете ли вы страницу 1 или страницу 1000. в основном вы сохраните «Смещение n строк только для выборки следующих m строк», но введете дополнительное предложение where «где [uniquesort_column]> [previous_page_last_unique_sort] «. Это предложение where будет молниеносным, потому что оно использует индекс так же, как и order by .

Так что да — я вроде как чувствую себя глупо, публикуя этот вопрос в первую очередь…поскольку основное предположение (порядок по делает запрос медленнее) НЕВЕРНО, если вы упорядочиваете по первичному ключу (ключам) в порядке его естественного индекса (при условии, что ВАША база данных работает так же, как и все базы данных, которые я тестировал …. что должно быть почти все из них … может быть, это дажев стандарте SQL … idk)