Використання IF у T-SQL послаблює або порушує кешування плану виконання?

Мені було припущено, що використання операторів IF у партіях t-SQL шкодить продуктивності. Я намагаюся знайти якесь підтвердження або підтвердити це твердження. Я використовую SQL Server 2005 та 2008 років.

Ствердження полягає в наступному:

IF @parameter = 0
 BEGIN
  SELECT ... something
 END

ELSE
 BEGIN
  SELECT ... something else
 END

SQL Server не може повторно використовувати створений план виконання, оскільки для наступного виконання може знадобитися інша гілка. Це означає, що SQL Server повністю виключить одну гілку з плану виконання на основі того, що для поточного виконання він вже може визначити, яка гілка потрібна. Це справді правда?

Крім того, що відбувається в цьому випадку:

IF EXISTS (SELECT ....)
 BEGIN
  SELECT ... something
 END

ELSE
 BEGIN
  SELECT ... something else
 END

де неможливо заздалегідь визначити, яка гілка буде виконуватися?

SQL Server оптимізує процес складання плану запитів для збереженої процедури, ігноруючи умовні гілки всередині збереженої процедури. План буде генерований на основі параметрів, використаних для першого виконання, це спричинить проблеми, якщо параметри для гілок різні.

Я б розмістив SQL для кожної з гілок у власну збережену процедуру, так що генерований план базується на фактичному використанні параметрів для цієї гілки.

Єдиним ярликом буде IF 1 = 1

І @parameter, і EXISTS все ще потребують обробки для "загального випадку" ( @parameter = 42скажімо)

Кажучи, що ... що говорить власне план виконання, а також профайлер, що фіксує події повторного виклику? (Мені не подобаються оцінені плани відповідно до відповіді Джао)

Спробуйте відобразити передбачуваний план виконання, а не фактичний. Ви побачите, що перший містить CONDоператора.

Цей оператор також був включений до плану кешованого виконання. У вашому прикладі орієнтовний план виправдання міститиме один оператор COND та 2 гілки SELECT і тому буде повністю використаний повторно. Тому що при виконанні пакетного SQL Server оцінює не тільки оператори DML, але й усі інші, отримуючи їх із плану.

План внутрішнього виконання - це структура, схожа на дерево виразів.

Плани створюватимуться на основі пропущених параметрів, так що насправді я б сказав, що ні - умовна логіка, яка зазвичай базується на параметрах, не шкодить продуктивності.

Ви отримаєте кілька планів, якщо припустити, що параметри викликають достатньо розбіжності, щоб оптимізатор запитів помітив.

Ви можете бачити, що, увімкнувши план Show Execution, запустивши сценарії - помітите відмінності в плані. Коли ви запускаєте процедури (я припускаю, що тут зберігаються процедури), ви помітите, що перший раз, як правило, швидше, при другому зверненні використовується збережений план. Змініть параметри та повторіть, а потім запустіть початкові параметри - теоретично план все ще буде в кеші, але це залежить від використання сервера (кеш-кліти - вони не залишаться назавжди ..) тощо.

Можливо, його було вдосконалено у 2005 та 2008 роках, але використання умовних умов у 2000 році було б швидше гіршим, ніж ви описуєте, воно склало б план, щоб найкраще обробити перший запуск процедури, а потім використати цей план для виконання процедури, навіть коли умови змінився. На моєму досвіді це спричинило запити, які проходили за лічені хвилини. Хоча я зараз використовую 2008 рік і використовував 2005 рік, я не можу коментувати, як працюють там кодиціонери, оскільки я більше не користуюся ними.