Все доброго дня.
Поставила меня в ступор следующая ситуация.

Имеем таблицу с кластерным уникальным индексам по полям Period+ID
Period - datetime2, ID - binary(16). Колонок > 2 (с десяток).
Таблица и кластерный индекс одинаково секционированы (одной функцией, по кварталам) по полю Period.
в таблице под 40 млн записей.

Имеем запрос вида



На совместимостях 110, 120 - работает прекрасно (CIseek).
При переключении на совместимость 130 - CIscan.
"Хм", подумал я... и пошел забавляться с флагами трассировки, статистикой, перестроением индекса и т.д.
Самое странное, что это даже не новый оптимизатор, т.к. на 120 - все ок (хотя как знать - новый активно развивают).

Оказывается, скуль (130) невзлюбил формат даты!
Любые другие варианты работают отлично
WHERE T._Period >= convert(datetime2, {ts '2018-08-01 00:00:00'})
WHERE T._Period >= '2018-08-01'
и т.п. - всегда CIseek

Может кто-нибудь объяснить В ЧЕМ ФИШКА?
Что случилось, если на более ранних совместимостях все прекрасно работало? Какие-то изменения может были правилах применения форматов дат?

PS: СУБД - mssql 2016 (enterprise) sp1 cu8

Гавриленко Сергей Алексеевич,
Содержимым запроса, текстом, параметрами управляет приложение. Я тут никак не повлияю.
Какой предикат в скане? Их там нет.
Поясните свои слова.
Преобразования над самим столбцомп (периодом) ведь не выполняются.
Попробовал воспроизвести на других данных без секционирования- пока не получается получить скан.

invm, виноват... ИхТамЕсть
......Period >= '2018-08-06 00:00:00.000'
При том что при "поиске по индексу" поиск по предикату выглядит так:
......Period >= Скалярный оператор('2018-08-06 00:00:00.0000000')

Значит ли это, что в первом случае СУБД не выполнила неявное преобразование значения и выполняется сравнение разных типов?

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

Какова вероятная причина такого поведения СУБД? Ошибка движка? До совместимости 130 этого косяка не было.

TaPaK, посмотрел, увидел.
Что-то в таком духе я и ожидал ((

Последний вопрос: MS это никак не исправляла? Так оно все и висит до последних версий?

авторЗачем исправлять то, что было сделано специально? Сидите на 120 CL, для того CL и придумали.
Т.е. в 130 они специально отказались от преобразования? Это где-то документировано?

alexeyvg, приложение совместимо с 2016.
Но тот функционал, на котором это проявилось - это интеграция с внешними базами, т.е. не часто используется и сделан по принципу "чтобы всем было хорошо". Поэтому тут даже не угадаешь и особо не протестируешь.
Конечно же установил 120. С этим нет проблем.

Единственное, что интересовало - причина.

Владислав Колосов, ну передать вендору ПО, что они новобранцы, я не смогу. До царя далеко. Но в поддержку обращусь )

Я кстати попробовал с не секционированной таблицей такой тест проделать.
В плане появляется вычисление скалярного значения, но уже работает быстро.

Прикрепил планы. 1-3 на секционированной таблице, 4-6 на не секционированной.

Оно и в нативном 110 так работает.
Нет. Написал же еще в шапке, что до <130 было все отлично. Прикрепил подтверждение (как и в предыдущем посте: 4-6 без секций)