Бывают дни, когда я хочу бросить всё это с кэшем планов и Хранилищем запросов!

Автор: Brent Ozar, There Are Days When I Feel Like Giving Up on the Plan Cache and Query Store

В теории мониторинг производительности SQL Server довольно прост:

1. Изучите главные типы ожиданий (wait types) на сервере.
2. Найдите запросы, вызывающие эти типы ожиданий.
3. Исправьте эти запросы или улучшите реакцию сервера на них (индексы, настройки и т.д.).

Но на практике шаг 2 ужасен, потому что:

• Приложения отправляют на сервер баз данных непараметризованные строки.
• Пользователи Entity Framework строят запросы с FromSqlRaw или string.Format().
• Пользователи Entity Framework пишут запросы с .Contains, который создаёт непараметризованный список IN, даже когда ищут всего одно значение (в EF9 стало лучше).
• Люди пишут неаккуратный динамический SQL, который просто вставляет значения прямо в строку запроса.
• Разработчики SaaS-решений помещают каждого клиента в собственную базу данных, и планы не переиспользуются между базами данных.

Устранение проблем соединений с 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 непосредственно внутри хранимой процедуры, вы часто играете в азартную игру с исполнительным движком. Давайте разберём, почему это происходит и как сохранить контроль.

Как выбор типа данных влияет на производительность

Автор: Paul Randal, How can data-type choice affect performance?

На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.

Проверка утилизации процессоров запросами за 45 секунд: от симптомов к первопричине

Автор: Luca Biondi, Check Top CPU Queries in 45 Seconds. From Symptoms to Root Clause. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 7

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

В двух словах

• ✔️ Время работы (Worker Time) против затраченного времени (Elapsed Time): Высокое время работы относительно продолжительности выполнения указывает на запрос, утилизирующий ЦП, или на высокий параллелизам. 
• ✔️ Анализ кэша планов (Plan Cache Mining): Используйте sys.dm_exec_query_stats, чтобы найти суммарное потребление ЦП с момента последнего перезапуска. 
• ✔️ Сосредоточьтесь на количестве выполнений: Запрос, который выполняется 1 миллион раз, потребляя по 10 мс, часто опаснее, чем запрос, выполняющийся один раз 10 секунд. 
• ✔️ Анализ первопричины: Чрезмерные сортировки, хэширование и скалярные пользовательские функции (Scalar UDF) — обычные подозреваемые в скачках ЦП. 

Проверка распределений памяти за 45 секунд: от симптомов к первопричине

Автор: Luca Biondi, Check Memory Grants in 45 Seconds. From Symptoms to Root Clause. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 6

Распределения памяти (memory grants) — это молчаливые убийцы конкурентности в SQL Server. В этой статье я покажу вам, как выявить запросы, пожирающие память, и устранить катастрофические ожидания типа RESOURCE_SEMAPHORE всего за 45 секунд — до того, как ваш сервер полностью остановится!

В двух словах

• ✔️ Распределения памяти предназначены для сортировки и хэширования: Это рабочая область оперативной памяти (workspace RAM), полностью отделённая от буферного пула, который кэширует страницы данных. 🛠️
• ✔️ Ожидания RESOURCE_SEMAPHORE: Главный красный флаг, указывающий на то, что запросы выстраиваются в очередь, испытывая голод по исполнительной памяти. 💣
• ✔️ Выявление виновников: Используйте sys.dm_exec_query_memory_grants, чтобы мгновенно обнаружить запросы, требующие непомерно больших, неоправданных объёмов оперативной памяти. 🧪
• ✔️ Устранение первопричины: В 99% случаев раздувание памяти вызвано устаревшей статистикой или плохим индексированием, а не недостатком физической оперативной памяти на сервере. ✔️

Сталкивались ли вы когда-нибудь со сценарием, когда ваш процессор практически простаивает, дисковый ввод-вывод находится в норме, но пользовательские приложения повсеместно завершаются по тайм-ауту? Добро пожаловать в ужасное узкое место RESOURCE_SEMAPHORE. Это происходит, когда ваш экземпляр исчерпывает рабочую область памяти для выполнения запросов. Давайте разберём, как диагностировать и исправлять проблемы с распределением памяти — от симптомов до первопричин — менее чем за минуту!

Проверка нагрузки на память за 45 секунд

Автор: Luca Biondi, Check Memory Pressure in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 4

В этой статье я покажу вам свой диагностический план из 5 шагов для выявления губительной нагрузки на память SQL Server менее чем за 45 секунд. Перестаньте гадать и начните точно определять, что именно лишает ваш буферный пул памяти, прежде чем производительность полностью деградирует!

В двух словах

• ✔️ Уровень ОС: Проверьте доступную физическую память – внешнее давление опасно 🛠️
• ✔️ PLE (Page Life Expectancy – ожидаемая продолжительность жизни страницы): Высокое значение – это хорошо, но внезапные падения означают активное перемещение данных в памяти (churn) 📉
• ✔️ Распределения памяти (Memory Grants): Долгие ожидания и огромные объёмы выделенной памяти – чистые убийцы параллелизма ⏳
• ✔️ Менеджеры памяти (Memory Clerks): Найдите, какой именно кэш (CACHESTORE, USERSTORE) ворует вашу оперативную память 🧠

Автоматическое исправление планов (Automatic Plan Correction) в SQL Server

Автор: theSQLSith, Query plan regressions got you down? Here's how can Automatic Plan Correction turns it around

Регрессии планов запросов донимают? Вот как автоматическое исправление планов (Automatic Plan Correction) может всё изменить.

Автоматическое исправление планов (Automatic Plan Correction, APC) — это одна из тех функций, о которой я довольно часто беседую с заказчиками, инженерами поддержки и широким сообществом SQL. Она входит в семейство автоматической настройки (Automatic Tuning) и незаметно выполняет свою работу, начиная с SQL Server 2017, обнаруживая регрессии планов запросов и автоматически принудительно применяя ранее известный хороший план для восстановления производительности. Но один из частых вопросов звучит так: как же APC на самом деле решает, произошла ли регрессия? И насколько оно уверено в этом решении?

Начиная с SQL Server 2022 CU4 и продолжая в SQL Server 2025, мы внесли значительные улучшения в статистическую модель, которую APC использует для обнаружения регрессий. В этой статье мы рассмотрим, что изменилось, почему это важно и как вы можете этим воспользоваться.

Проверка узких мест ввода-вывода за 45 секунд

Автор: Luca Biondi, Check IO Bottlenecks in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 5

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

В продолжение темы о промежуточной материализации (сбросе) в TempDB

Автор: Luca Biondi, Why SQL Server Starts Spilling to TempDB

Как мы говорили в предыдущей статье: когда загрузка ЦП в порядке, операции ввода-вывода в порядке, а запросы выглядят «нормально», но производительность нестабильна: иногда быстро, иногда медленно – настоящая проблема часто кроется в сбросах в TempDB. В этой второй части мы глубже разберём первопричину!

Ошибка в sys.dm_exec_query_plan_stats

Автор: Brent Ozar, There’s a Bug in sys.dm_exec_query_plan_stats.

Когда вы включаете последние актуальные планы в SQL Server 2019 и новее:

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

Системная функция sys.dm_exec_query_plan_stats должна показывать последний актуальный план запроса. Мне эта штука то попадалась, то нет, но моя последняя проблема с ней заключается в том, что два числа откровенно неверны. Она путает время CPU и прошедшее время.

Углублённая диагностика и информативные панели мониторинга

Автор: Pinal Dave, Deeper Diagnostics and Actionable Dashboards

Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.

Как не работают многоколоночные статистики

Автор: Brent Ozar, How Multi-Column Statistics Work

Короткий ответ: в реальном мире работает только первая колонка. Когда SQL Server нужны данные о второй колонке, он строит собственную статистику по этой колонке (предполагая, что она ещё не существует) и использует эти две статистики вместе — но они не коррелируют друг с другом.

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 был спроектирован для работы.

Ваш план исполнения лжёт Вам...и Вы об этом не догадываетесь

Автор: Luca Biondi, 😈 Your Execution Plan Is Lying to You ...And You Don’t Know It

уверен, что это случится с вами в какой-то момент... и с множеством ваших коллег также. Клиент сообщает вам, что ваше приложение работает крайне медленно. Вы уже идентифицировали проблемный запрос и…

Исполнение плана выглядит идеально…
но ваш запрос всё ещё медленно работает.

👉 Что-то лжёт вам.

И нет… не SQL Server! ....это то, как вы читаете план выполнения.

Перегружена ли индексами ваша база данных?

Автор: Luca Biondi, Is Your Database Over-Indexed? Your Indexes Might Be Killing Performance

👉 Если вы пропустили мою предыдущую статью, ознакомьтесь с ней здесь: Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Ваш запрос работает медленно.
И вы добавляете индекс.

Запрос ускоряется… на мгновение.

Но затем всё остальное начинает работать медленнее.

👉 Что же произошло?

Возможно, вы перегружаете свою базу данных индексами.

Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction

Автор: Luca Biondi, Stop Defragmenting indexes: Auto Index Compaction feature preview in SQL Server – This Feature will Kills Index Maintenance Jobs!

В предыдущей статье мы проанализировали улучшения производительности в SQL Server 2025 CU3 и обнаружили скрытые оптимизации, о которых никто не говорит.

👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит

В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).

Самая распространённая ошибка индексирования в SQL Server (и как её исправить)

Автор: Luca Biondi, The Most Common SQL Server Indexing Mistake (And How to Fix It)

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

Как удалось убрал 32 секунды из запроса без добавления индекса

Автор: Luca Biondi, I Removed 32 Seconds From This SQL Server Query ...Without Adding an Index! Part 7

Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.

Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.

Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.

Просто понимание того, как работает движок.

Приятного чтения — давайте заставим SQL Server летать.

Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

Стратегии индексирования для производительности SQL Server

Автор: Paul Randal, SQL101: Indexing Strategies for SQL Server Performance

Один из самых простых способов повысить производительность запросов в SQL Server — обеспечить быстрый доступ к запрашиваемым данным, причём максимально эффективно. В SQL Server использование одного или нескольких индексов может стать именно тем решением, которое вам нужно. Фактически, индексы настолько важны, что SQL Server может даже предупредить вас, когда обнаружит, что отсутствует индекс, который был бы полезен для запроса. Это обзорная статья объяснит, что такое индексы, почему они так важны, а также немного об искусстве и науке разработки различных стратегий индексирования.

Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)

Автор: Luca Biondi, Still on Batch Mode… – Part 6: Compatibility & Query Settings That Influence Execution

Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)

Мы всё ещё говорим о пакетном режиме, потому что понимание того, когда он работает, так же важно, как и знание того, как его принудительно включить.

Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.

Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!