Sql server: міф про передбачувані плани виконання

Відео: SQL Server. Про найчастішою причини вибору неефективного плану запиту. Частина 1

Візьмемо базовий запит:

і помістимо його в середу SQL Server Management Studio. Після цього натискаючи комбінацію клавіш і отримаємо Ctrl-L план виконання - представлений на скріншоті нижче.


Це передбачуване виконання. Крім того, це і фінальний план виконання. Якщо ви натиснете на клавіатурі комбінацію клавіш Ctrl-M і потім виконайте запит, то отримаєте набір результатів і наступний, вже фактичний план виконання (див. Скріншот нижче).





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




При дуже уважному розгляді ви можете помітити в згаданих графічних планах одна відмінність. Конвеєр, що представляє потік даних між оператором Nested Loops і виконуваної в таблиці ProductCategory операцією Clustered Index Seek, виявляється фактично трохи більше «товстим» (див. Скріншот нижче).


Це пояснюється одним з тих нечисленних відмінностей, які характеризують передбачуваний план. До складу фактичного плану зазвичай входить декілька метрик часу виконання. Середньостатистичний оператор, який використовується в плані виконання. зазвичай має чотири додаткових властивості для фактичного плану:
• RuntimeCountersPerThread;
• ActualRows;
• ActualEndOfScans;
• ActualExecutions.

От і все. Згадані властивості фіксуються тільки під час виконання. У нашому графічному плані передбачуване число рядків становить 1, а фактичне число - 8. Це і пояснює вельми незначне розходження в розмірах конвеєра. Ви можете переконатися в цьому, перевіривши властивості оператора (див. Скріншот нижче).


Справа не тільки в тому, що передбачуваний і фактичний плани по суті збігаються. Якщо ви направите в кеш плану запит з метою отримання плану виконання, то виявите, що план, який зберігається всередині SQL Server і раз по раз використовуваний для виконання запитів, являє собою передбачуваний план. Ніяких даних, що відносяться до часу виконання, в ньому немає. Прошу зрозуміти мене правильно. Фактичні плани виключно корисні, оскільки містять дані, пов`язані з часом виконання. Припустимо, оптимізатор вважав, що витягне один рядок даних, а фактично витягнув 100, 1000 або 1 млн рядків. Так ось, знати про це надзвичайно важливо при виконанні настройки запиту. Але інші відомості, які ми отримували з планів виконання, ідентичні. Ось чому не слід відмовлятися від використання передбачуваних планів виконання.

---

Чи плануєте вивчати SQL Server самостійно? Тоді перед цим вам необхідно пройти курси англійської (https://soho-bridge.ru/kursy-anglyskogo-yazyka/). Справа в тому, що вся технічна документація і більшість слушних самовчителів видані саме на англійській мові.