Шановний [твоє ім’я тут]!
О ні, мені шкода це чути! Почнемо з декількох основ, щоб ви зафіксувались на мить.
Те, з чим ви стикаєтесь, називається Parameter Sniffing
Це вихід з дивовижною проблемою віггі. Назва перекочується прямо з язика. Як німецьке слово для білки.
І це, як правило, твій друг.
Коли запит потрапляє на ваш сервер, план повинен бути складений. Щоб згодом заощадити час та ресурси, план виконання кешується на основі оціночних рядків, параметр яких призведе до обробки та повернення коду.
Найпростіший спосіб уявити це погано - це уявити збережену процедуру, яка потребує підрахунку речей з двох груп, що перебувають у розрізі.
Наприклад:
Люди, які носять футболки CrossFit, які не постраждали: Нуль
Люди, що носять сорочки CrossFit, які мряться, коли зморщуються: Усі
Очевидно, що при одному виконанні цього коду доведеться зробити набагато більше роботи, ніж інший, і плани запитів, які ви хочете виконати абсолютно різними обсягами роботи, виглядали б зовсім інакше.
Що я проти?
Це справді складна проблема знайти, протестувати та виправити.
- Це важко знайти, оскільки це не відбувається послідовно
- Це важко перевірити, оскільки потрібно знати, які параметри викликають різні плани
- Це важко виправити, оскільки іноді потрібна налаштування запитів та індексів
- Це важко виправити, тому що ви, можливо, не зможете змінити запити чи індекси
- Це важко виправити, оскільки навіть якщо ви зміните запити чи індекси, вони все одно можуть повернутися
Швидкі виправлення
Іноді все, що вам потрібно, - це трохи ясності. А точніше, кеш вашого плану робить.
Якщо це збережена процедура
Спробуйте запустити EXEC sys.sp_recompile @objname = N'schema.procname'. Це спричинить процедуру перекомпіляції нового плану при наступному запуску.
Що цього не виправить:
Що це не гарантує:
- Наступний процес, який запускається після перекомпіляції, використовуватиме параметр, який дає вам хороший план.
Ви також можете вказати sp_recompileна таблицю або перегляд, але попередивши, що весь код, який торкається цієї таблиці чи перегляду, буде перекомпільований. Це може значно ускладнити проблему.
Якщо це параметризований запит
Ваша робота трохи складніше. Вам потрібно буде відстежити ручку SQL. Ви не хочете звільнити весь кеш плану - подібно до використання sp_recompileтаблиці або перегляду, ви можете викликати (ха-ха-ха) цілу купу непередбачуваних наслідків.
Найпростіший спосіб визначити цю команду - запустити sp_BlitzWho *! Існує стовпець під назвою "виправити параметр нюхання", який має команду для видалення одного плану з кешу. Однак це має ті ж недоліки, що і перекомпіляція.
Що цього не виправить:
Що це не гарантує:
- Наступний процес, який запускається після перекомпіляції, використовуватиме параметр, який дає вам хороший план.
Мені ще потрібна допомога!
Нам знадобляться такі речі:
- Хороший план запитів, якщо це можливо
- Поганий план запитів
- Використовувані параметри
- Запит, про який йдеться
- Визначення таблиці та індексу
Отримання планів запитів та запитів
Якщо запит запущений, ви можете використовувати sp_BlitzWho * або sp_WhoIsActive для зйомки поточних запитів, що виконуються.
EXEC sp_BlitzWho;
EXEC sp_WhoIsActive @get_plans = 1;
Якщо запит наразі не виконується, ви можете перевірити його у кеші плану, використовуючи sp_BlitzCache *.
Якщо ви перебуваєте на SQL Server 2016+ та увімкнено магазин запитів, ви можете використовувати sp_BlitzQueryStore *.
EXEC dbo.sp_BlitzCache @StoredProcName = 'Your Mom';
EXEC dbo.sp_BlitzQueryStore @StoredProcName = 'Your Mom';
Це допоможе вам відстежити кешовану версію (-ів) вашої збереженої процедури. Якщо це просто параметризований код, ваш пошук трохи складніше. Це може допомогти, хоча:
EXEC dbo.sp_BlitzCache @QueryFilter = 'statement';
Ви повинні побачити досить схожий результат з будь-якого з них. Знову, план запитів із запрошенням прохолодного синього клацаючого стовпця - це ваш друг.
Найпростіший спосіб поділитися планами - це використовувати Paste The Plan * або скидати XML у пастину. Для цього натисніть будь-який із тих, хто запрошує сині кліки колонки. План запитів повинен з’явитися на новій вкладці SSMS.
Якщо вам не подобається ділитися кодом і запитом вашої компанії, ви можете скористатися безкоштовним інструментом програми Explorer Sentry One для анонімності вашого плану. Майте на увазі, це ускладнює отримання довідки - анонімований код набагато складніше читати та розбирати.
Усі ці інструменти, про які ми говорили, повинні повертати текст запиту. Тут вам більше нічого не потрібно робити.
Отримати параметри (и) трохи складніше. Якщо ви використовуєте План Провідник , внизу є вкладка, у якій перераховано їх усі.
Якщо ви використовуєте sp_BlitzCache *, є стовпчик, що можна натискати, який дає вам заяву про виконання збережених процедур.
Отримання визначень таблиці та індексу
Ви можете легко клацнути правою кнопкою миші в SSMS, щоб виправити речі.
Якщо ви хочете отримати все за один кадр, sp_BlitzIndex * може допомогти, якщо навести його прямо на стіл.
EXEC dbo.sp_BlitzIndex @DatabaseName = 'StackOverflow2010',
@SchemaName = 'dbo',
@TableName = 'Users';
Це дасть вам визначення таблиці (хоча не як оператор створення) та створить оператори для всіх ваших індексів.
Збираючи та додаючи цю інформацію до свого запитання, люди повинні отримати достатньо інформації, щоб допомогти або направити вас у правильному напрямку.
Я хочу зробити це сам!
Ну, круто. Я радий за вас. Ти божевільна людина.
Є багато способів, на які люди думають, що вони "виправляють" нюхання параметрів:
Але вони справді відключають нюхання параметрів різними способами. Це не означає, що вони не можуть вирішити проблему, вони просто не дійсно до першопричини.
Це тому, що потрапити до першопричини, як правило, важко. Ви повинні шукати ті прискіпливі "питання якості" плану.
Починаючи з планів швидких проти повільних, шукайте відмінності на зразок:
- Використовувані індекси
- Приєднуйтесь до замовлення
- Серіал проти паралелі
Також шукайте різних операторів, які роблять ваш код чутливим до нюху параметрів:
- Пошук
- Сорти
- Тип приєднання
- Надані пам’яті (і за розширенням, розливи)
- Шпулі
Не зациклюйтеся на пошуках проти сканування, фрагментації покажчиків чи будь-якого з культових вантажів, які люди нап’ють і роблять.
Зазвичай існує досить основна проблема індексації. Іноді код потрібно трохи переписати.
Якщо ви хочете дізнатися більше про нюхання параметрів:
Якщо ви читаєте це, і ви думаєте, що я пропустив посилання або корисний інструмент, залиште коментар. Я зроблю все можливе, щоб це було актуальним.