SQL Server Parameter Sniffing: ошибка, которая не является ошибкой (но всё ломает)

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье вы узнаете, как выявить и победить нестабильную производительность в SQL Server. Если ваши запросы без предупреждения переходят от «молниеносных» к «еле ползущим», вы стали жертвой Parameter Sniffing. Пришло время вернуть контроль над вашими планами выполнения и остановить непредсказуемость.

Ваш запрос работает быстро, а затем внезапно… становится медленным!
У вас есть:

• Тот же запрос.
• Те же данные.
• Тот же сервер.

👉 Что изменилось?

💣 Parameter Sniffing. И нет… это НЕ ошибка. Это то, как SQL Server был спроектирован для работы.

Sniffing параметров в SQL Server

Автор: Vivek Johari, Parameter Sniffing in SQL Server

"Parameter Sniffing" (конфиденциальность параметров) в SQL Server происходит, когда план выполнения запроса генерируется с использованием конкретных значений параметров. Последующие выполнения того же запроса могут работать плохо с другими значениями параметров из-за неподходящего кэшированного плана. Вот как можно решить эту проблему:

Оптимизация чувствительных к параметрам планов исполнения в SQL Server 2022

Автор: Deepam Ghosh, Parameter Sensitive Plan Optimization in SQL Server 2022

SQL Server 2022 включает множество усовершенствований и новых возможностей по сравнению с предыдущими версиями. Среди них новые роли сервера, улучшенный Query Store, повышение производительности TempDB, интеллектуальная обработка запросов, автономные группы доступности, Database Ledger и многое другое.

В сегодняшней статье мы рассмотрим практическую демонстрацию одной из таких возможностей — оптимизации планов, чувствительных к параметрам (Parameter Sensitive Plan Optimization, PSPO). Мы увидим, какие трудности создают параметризованные хранимые процедуры в старых версиях и как оптимизация PSPO решает эти проблемы и улучшает планы выполнения запросов в новой версии.

Эта статья посвящена только практической части, для изучения подробной теории об оптимизации планов, чувствительных к параметрам, обратитесь к официальной документации Microsoft.

Устранение проблем соединений с TVP

Автор: Luca Biondi, Check SQL Server TVP Join Problems in 45 Seconds ...Bad Estimates, TempDB Spills, and Parameter Sniffing | Part 17

В этой статье вы узнаете, почему соединение с Table-Valued Parameters (TVP) может разрушить вашу производительность из-за скрытых сбросов в TempDB и как это исправить с помощью надёжного, готового к проду шаблона.

🧠 В двух словах

• ✔️ Статистическая слепота: TVP не хватает статистики распределения, что заставляет оптимизатор делать зафиксированные предположения о кардинальности. 💣
• ✔️ Памятная катастрофа: Заниженные оценки количества строк приводят к недостаточному распределению памяти и массовым сбросам сортировок и хэш-операций на диск (в TempDB). 🚀
• ✔️ Ловушки sniffing'а: Кэширование планов для маленьких наборов данных в TVP приводит к полному отказу, когда позже передаются большие объёмы данных. ✔️

В высокопроизводительных SQL-средах мы полагаемся на TVP для эффективной передачи наборов данных. Но есть и тёмная сторона. Когда вы выполняете соединение (JOIN) с TVP непосредственно внутри хранимой процедуры, вы часто играете в азартную игру с исполнительным движком. Давайте разберём, почему это происходит и как сохранить контроль.

Проверка состояния TempDB за 45 секунд

Автор: Luca Biondi, SQL Server Parameter Sniffing: The Bug That Isn’t a Bug (But Breaks Everything)

В этой статье я покажу вам, как обнаружить нагрузку на TempDB менее чем за 45 секунд и, что ещё важнее, — как правильно её интерпретировать.
Потому что выявление истинного узкого места — это то, что отличает реактивных администраторов баз данных от инженеров по производительности.

Когда сервер работает медленно, но метрики CPU и ввода-вывода выглядят нормально. Когда планы выполнения выглядят приемлемо, но что-то всё равно не так. Когда запросы нестабильны — то быстры, то еле ползут — и пользователи жалуются, хотя вы не видите ничего очевидного...

Вот где многие администраторы баз данных тратят часы.

👉 Помните: TempDB часто оказывается замешана, но почти никогда не является первопричиной.

Десять лучших практик настройки производительности SQL Server

Автор: Paul Randal, SQL101: Top Ten SQL Server Performance Tuning Best Practices

Существует огромное количество лучших практик по настройке производительности SQL Server — я мог бы легко написать целую книгу на эту тему, особенно учитывая множество различных настроек базы данных, настроек сервера, практик написания кода, типов ожидания и так далее, которые могут влиять на производительность. Для этой статьи я решил немного отступить от списка конкретных деталей и дать несколько общих рекомендаций о том, как подходить к настройке производительности, чтобы максимизировать усилия и минимизировать отвлекающие факторы.

Сравнение одноколоночных, многоколоночных и фильтрованных статистик в SQL Server

Автор: Kendra Little, Comparing Single Column, Multi-Column, and Filtered Statistics in SQL Server

Статистики в SQL Server теоретически просты: они помогают оптимизатору оценить, сколько строк может вернуть запрос.

На практике? Всё быстро становится странным. Особенно когда вы начинаете фильтровать по нескольким столбцам или задаётесь вопросом, почему оптимизатор думает, что вернутся миллионы строк, когда вы знаете, что их всего несколько сотен тысяч.

В этой статье я на примерах разберу одноколоночные, многоколоночные и фильтрованные статистики — покажу, в каких случаях оценки не соответствуют действительности, когда они приходят в норму и почему это не всегда означает, что нужно обновить всё с помощью FULLSCAN.

Использование статистики оптимизатором запросов Microsoft SQL Server 2005

По материалам статьи Eric N. Hanso: Statistics Used by the Query Optimizer in Microsoft SQL Server 2005

Microsoft SQL Server 2005 собирает статистику по индексам и полям данных, хранимых в базе. Эта статистика используется оптимизатором запроса SQL Server при выборе оптимального плана исполнения запросов на выборку или обновление данных. В этой статье описывается то, какие данные собираются сервером, где они хранятся, и какие команды нужно использовать для обновления и удаления статистики. По умолчанию, SQL Server 2005 создает и обновляет статистику автоматически, когда решит, что это будет полезным. В этой статье описано, как можно изменять заданные по умолчанию значения конфигурации сбора статистики на разных уровнях (столбец, таблица и база данных).