Непристойное поведение select в mssql

[Antonariy]

Есть процедура такого вида:

alter PROCEDURE udGetList
@ProjectID int,
@OperatorID int=0
AS

declare @optype int
select @optype = OperatorTypeID from tblOperators where OperatorID=@OperatorID

select * from cvOrganisationsList
where ProjectID = @ProjectID and (
OperatorID = @OperatorID or
OperatorID = null or
@OperatorID = 0 or
@optype=1)

Если убрать выделенную строчку, то записи возвращаются в порядке, предусмотренном индексами. А при ее наличии записи возвращаются в произвольном порядке, всегда разном. С чем это связано?

[Ennor]

в порядке, предусмотренном индексами.

Нет такого порядка больше, и уже давно. Начиная с версии 7.0, сиквел не гарантирует никакого порядка, если явно не указан ORDER BY. Просто прими это как данность и не парься больше.

Т.е. он и раньше ничего не гарантировал, но внутренняя зависимость была, и довольно простая. Теперь там все сложнее.

[GSerg]

И... можно нескромный вопрос...

OperatorID = null

Это когда-то выполняется?..

[VVitafresh]

И... можно нескромный вопрос...

OperatorID = null

Это когда-то выполняется?..

Неа.

Код: Выделить всё

OperatorID IS NULL

[Ennor]

Епрст. Antonariy, прикалываешься?

where ProjectID = @ProjectID and (
OperatorID = @OperatorID or
OperatorID = null or
@OperatorID = 0 or
@optype=1)

Ты в условии запроса проверяешь значение переменной, а не столбца. Неудивительно, что план начинает строиться совершенно по-другому

Да, и последнее: данный набор OR'ов (за вычетом этой проверки, разумеется) можно заменить такой вот изящной конструкцией:

Код: Выделить всё

where ProjectID = @ProjectID
  and (nullif(OperatorID, @OperatorID) is null
    or @optype=1)

Вообще же считается, что MSSQL плохо переваривает OR-условия; так что, если будут проблемы с производительностью, попробуй переписать запрос в виде UNION.

[Antonariy]

И... можно нескромный вопрос...

OperatorID = null

Это когда-то выполняется?..

Постоянно переключаюсь sql - javascript - vb. Уже иногда в вб пишу if x==

Нет такого порядка больше, и уже давно.

По-моему теперь прикалываешься ты. select * from tbl всегда возвращает записи в порядке, указанном кластерным индексом. А кластерный индекс и физически и логически выстраивает записи указанным порядком. В чем по-твоему смысл сортировки полей индексов, если они нихрена не гарантируют?

Ты в условии запроса проверяешь значение переменной, а не столбца. Неудивительно, что план начинает строиться совершенно по-другому

Все прикалываешься? А как насчет @optype=1? Ее наличие/отсутствие на порядок не влияет.

[Antonariy]

Вопрос более не актуален. Переделал логику и нужда в проверке @OperatorID = 0 отпала.

[Konst_One]

нет порядка записей в возвращаемом резалтсете в сиквеле
всегда случайным образом

если нужен порядок, то обязательно надо использовать сортировку:

Код: Выделить всё

ORDER BY Field1 ASC{DESC}

[Antonariy]

Если в ста случаях из ста записи возвращаются в ожидаемом порядке, о какой случайности может идти речь? Или ты имеешь ввиду, что каждый раз случайно записи возвращаются без order by так как угодно мне? Обоснуй доказательно свои слова. Лично я руководствуюсь этим:

Clustered indexes have one row in sysindexes with indid = 1. The pages in the data chain and the rows in them are ordered on the value of the clustered index key. All inserts are made at the point the key value in the inserted row fits in the ordering sequence.

[Konst_One]

Цитату, что ты привел , никак нельзя соотнести с задачей, которую ты пытаешься решить. Там нет ни слова о порядке вывода записей при выборке данных из такой таблицы. Наверное ты слышал о секционировании, это так к слову.

Любая DBMS, основанная на стандартах SQL, выводит гарантированно сортированный набор данных только при наличии ORDER BY в предложении на выборку - это аксиома.
Из опыта могу заметить, что кластерный PK не является гарантией такого результата в MSSQL (как впрочем и в Oracle и тд и тп). Искать подтверждения моим словам можешь в документации по MSSQL на MSDN и в публикациях от мелкософта, но это точно где-то есть, поверь мне.

[Antonariy]

Действительно, я слегка погорячился
На запросах, где join'ов побольше, записи возвращаются несортированные, но всегда в одном и том же порядке. Так что самый певый вопрос все равно меня смущает, хотя уже не актуален.

[HandKot]

Любая DBMS, основанная на стандартах SQL, выводит гарантированно сортированный набор данных только при наличии ORDER BY в предложении на выборку - это аксиома.
Из опыта могу заметить, что кластерный PK не является гарантией такого результата в MSSQL (как впрочем и в Oracle и тд и тп). Искать подтверждения моим словам можешь в документации по MSSQL на MSDN и в публикациях от мелкософта, но это точно где-то есть, поверь мне.

т.к в MS SQL существует оптимизатор запросов, то
оный оптимизатор и является причиной того, что записи возвращаются в одном и том же порядке + использование сервером КЭША (хотя в некоторых случаях порядок может и нарушаться)

Если убрать выделенную строчку, то записи возвращаются в порядке, предусмотренном индексами. А при ее наличии записи возвращаются в произвольном порядке, всегда разном. С чем это связано?

сравните планы выполнения запросов и может это чем-то вам поможет

[Konst_One]

и главное в самый неподходящий момент, как всегда