Добрый день, коллеги.

Недавно в ходе раздачи указаний подвластным мне серверам MS SQL я наткнулся на каприз с их стороны. Приведу скрипт, воспроизводящий ситуацию:

Этот скрипт выполняется посредством ступенчатых Merge Join (Concatenation); но если я добавляю в конкатенацию еще один селект, сервер меняет план выполнения на Concatenation и последующий Sort. Применение хинта OPTION (MERGE UNION) привело к сидячей забастовке - ответу "Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN."

На реальных данных такое поведение меня не совсем устраивает, стоимость плана возрастает более чем на порядок. Не то чтобы это стало для меня проблемой (много очевидных воркароундов, из которых выбран простейший - я стал забирать несортированный поток и сортировать сам). Но хотелось бы иметь прямые средства воздействия на оптимизатор сервера, который, видя более чем 64 таблицы в запросе, отвечает мне: "Я девочка. Я не хочу ничего решатьоптимизировать. Я хочу платьеконкатинировать." Я поискал их, но не нашел, если кто-то знает их, то прошу сообщить мне.

Гавриленко Сергей АлексеевичЛютый бред какой-то. Зачем 64 раза селектить пустую таблицу в одном запросе? А не пустую?
Вы прямо как наш родной МИД. Пожалуйста, читайте внимательнее написанное мной.

Вы спрашиваете, зачем селектить пустую таблицу? Потому что "скрипт, воспроизводящий ситуацию". Зачем мне создавать 64 таблицы, если на одной происходит то же самое? Более того, я единственное поле оставил по той же причине. И с пустотой та же петрушка - я прямо указал, что происходит на моих реальных данных.

invmНашинкуйте на фрагменты:
Это воркароунд, были мысли о нем, но не счел оптимальным. Ибо запрос создается динамически (для разных таблиц), и в таких ситуациях я всячески избегаю делать навороты в генерируемом содержимом.
TaPaK.Евгений,
Воспроизвести в общем-то не получилось, но и SP1-CU5 нет...
Аналогичный план для Microsoft SQL Server 2012 (SP4) (KB4018073) - 11.0.7001.0 (X64)
А на какой версии этой смены плана не происходит?

TaPaKплан менятся, ошибок нет
Я правильно понял, что у вас при объединении 65 экземпляров таблицы и указании хинта OPTION (MERGE UNION) создается план с конкатенациями, но ошибки "Query processor could not produce..." не происходит?

В общем, если кто-то найдет ссылку на документацию, описывающую поведение сервера в данной ситуации, или знает какую-то дубину (трейсфлаг и т.п.), посредством которой моих "девочек" можно насильно заставить сделать мне Merge Join 65 раз подряд - буду рад услышать. Не услышу - продолжу пользоваться воркароундами, которые сочту оптимальными в той или иной ситуации.

P.S. Небольшой комментарий на тему "зачем". У меня организован архив входящих сообщений, разбитый на отдельные таблицы (ради управляемости, согласно типу и году-месяцу). Иногда эти сообщения нужно перечитать (и перезагрузить их содержимое в ХД) в порядке возрастания идентификатора. Шесть типов за год - вот мне и каприз.