Було б краще, щоб плани запитів були розділені заявою для повторної використання?

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

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

Моє запитання: Якщо користувач виконує оператор, який є одним із висловлювань запиту з декількома операторами, чи може він використовувати ту відповідну частину плану запитів, яка вже є в кеші для запиту з декількома операторами? Я очікую, що відповідь - ні, тому що значення хешів, очевидно, не збігаються, але було б краще хешировать кожне твердження в запиті з декількома операторами, щоб їх могли використовувати користувачі, які виконують окремі заяви з запиту?

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

Хоча якраз може виявляти моє невігластво.

Якщо користувач виконує оператор, що є одним із висловлювань запиту з декількома операторами, чи може він використовувати ту відповідну частину плану запитів, яка вже знаходиться в кеші для запиту з декількома операторами?

Ні. Основна одиниця повторного використання плану в SQL Server - це пакетна .

Було б краще хеш-версію кожного оператора в запиті з декількома операторами, щоб їх могли використовувати користувачі, які виконують окремі заяви із запиту?

Система, налаштована на високий рівень повторного використання плану, розміщує загальний код (при відповідній деталізації) в об'єктах багаторазового використання (наприклад, процедури, функції, тригери) на SQL Server. Він також буде явно параметризувати будь-який згенерований додатком або код на стороні клієнта. Для максимального повторного плану ці генеровані партії повинні відрізнятися лише значеннями параметрів.

Я думаю, що є ускладнення, які я не беру до уваги

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

Є кілька речей, які роблять партії не зовсім автономними (наприклад, створені локальні тимчасові таблиці та посилання через межі збережених процедур). Ці винятки зменшують ортогональність і протягом багатьох років асоціюються з несподіваною поведінкою та помилками «дизайнерських».