Что такое остаточный предикат (residual predicate) и почему это плохо?

Автор: Brent Ozar, Database Animations: What’s a Residual Predicate and Why Is It Bad?

Обычно, когда вы смотрите на план выполнения и видите поиск по индексу (index seek), за которым следует поиск по ключу (key lookup), это означает, что запрос выполняется относительно быстро.

Уровень совместимости и оценщик кардинальности в SQL Server

Автор: Vivek Johari, Compatibility Level vs. Cardinality Estimator in SQL Server: A Complete Guide;

Если вы когда-либо занимались настройкой производительности SQL Server, вы почти наверняка сталкивались с двумя терминами, которые постоянно путают: уровень совместимости (Compatibility Level, CL) и оценщик кардинальности (Cardinality Estimator, CE). Они звучат так, будто могут быть одним и тем же, поскольку изменение одного часто влияет на поведение другого. Но это два разных понятия в ядре SQL Server, и понимание того, где они пересекаются, а где расходятся, необходимо для всех, кто занимается обновлениями, миграциями или настройкой запросов.

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

Промежуточная материализация (Query Memory Spills)

Автор: Klaus Aschenbrenner, Query Memory Spills

Иногда, когда вы смотрите на планы выполнения, вы можете увидеть, что у оператора SELECT иногда есть так называемый грант памяти (Memory Grant). Этот грант памяти указывается в килобайтах и необходим для выполнения запроса, когда некоторым операторам (например, Sort/Hash) в планах выполнения требуется память для выполнения — так называемая память запроса (Query Memory).

Новое в SQL Server 2025: Мультипликативная агрегация с функцией PRODUCT

Автор: Leonard Lobel, Multiplicative Aggregates with the PRODUCT Function in SQL Server 2025

В этой статье блога рассматривается новая функция PRODUCT в SQL Server 2025, которая вычисляет произведение набора числовых значений — аналогично тому, как SUM и AVG работают для сложения и усреднения, но для умножения.

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

PRODUCT поддерживает как агрегатную, так и аналитическую (оконную) формы и работает как со значениями ALL (по умолчанию), так и с DISTINCT. Значения NULL игнорируются, и функция совместима со всеми числовыми типами, кроме bit.

Проблемы производительности из-за ORDER BY/GROUP BY — сбросы в tempdb

Автор: Sarjen Haque, Performance issues from ORDER BY/GROUP BY - spills in tempdb

Совершенно обычно и ожидаемо видеть запрос, содержащий предложение ORDER BY или GROUP BY для целей отображения или группировки. Также часто разработчики используют предложение ORDER BY по привычке, не задумываясь о его необходимости. В результате запросы со временем замедляются по мере увеличения количества записей.

Когда происходят сбросы (spill) для Hash, Sort и Exchange

Автор: Remus Rusanu, Understanding Hash, Sort and Exchange Spill events

Некоторые операции при выполнении запросов SQL Server рассчитаны на наилучшую производительность при использовании (относительно) большого объёма памяти в качестве промежуточного хранилища. Оптимизатор запросов выбирает план и оценивает стоимость, основываясь на том, что эти операторы используют эту «черновую» память. Но это, конечно, лишь оценка. Во время выполнения оценки могут оказаться неверными, и план должен продолжить работу, несмотря на нехватку памяти. В таком случае эти операторы выполняют сброс на диск (spill). Когда происходит сброс, «черновая» память сбрасывается в tempdb, и новые данные размещаются в (теперь) свободной памяти. Когда данные, сброшенные в tempdb, снова нужны, они читаются с диска. Само собой разумеется, сброс в tempdb на порядок медленнее, чем использование только «черновой» памяти. Мониторинг сбросов особенно важен в ETL-задачах, поскольку эти случаи могут растянуть выполнение ETL на многие минуты, а иногда даже часы. Для исчерпывающего обсуждения ETL, включая некоторые ссылки на сбросы, см. Руководство по производительности загрузки данных.

Что происходит с данными и журналом при сбросах в tempdb

Автор: Paul Randal, Understanding data vs log usage for spills in tempdb

В списке рассылки SQL MCM (в котором участвуют все действующие инструкторы MCM) было обсуждение, где пытались понять огромное несоответствие между использованием файлов данных tempdb и файлов журнала. Я объяснил ответ и решил поделиться им со всеми вами.

Расчёт задержки в сети между репликами группы доступности Always On

Автор: Paul Ou Yang, Calculating Network Latency Between Always On Availability Group Replicas

У нас было бизнес-требование добавить облачную асинхронную реплику к локальной группе доступности SQL Server Always On. После добавления высоконагруженной базы данных в группу доступности мы заметили, что очередь отправки журнала начала быстро расти.

Нашим первоначальным подозрением было, что задержка в сети между локальной первичной репликой и облачной репликой вносит вклад в проблему. Однако прежде чем запрашивать модернизацию сети, нам нужен был способ доказать, что производительность сети действительно влияет на перемещение данных.

Один из полезных подходов — использовать трассировку Extended Events для перемещения данных Always On, описанную в статье Microsoft: Устранение задержек перемещения данных между группами доступности AlwaysOn с синхронной фиксацией

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

Управление кешем планов SQL Server: диагностика и решение проблем

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

• Как работают корзины (buckets) в кеше планов
• Как диагностировать проблемы с неравномерным распределением планов
• Как выявлять проблемные запросы и процедуры
• Стратегии решения проблем без использования регламентированных запросов

Адаптивный мониторинг актуальности статистики в SQL Server

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

Лучшая пожарная сигнализация — всё равно пожар

Автор: Pinal Dave, A Better Fire Alarm Is Still a Fire

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

Почему большие столбцы могут не влиять на логические чтения

Автор: Brent Ozar, Database Animations: Why Big Columns May Not Affect Logical Reads

Со временем таблицы — как и наша талия — имеют свойство увеличиваться. Мы постоянно добавляем всё новые и новые столбцы, один за другим, чтобы удовлетворить потребности приложений. Добавить «ещё один столбец» проще, чем выносить что-то в отдельную таблицу.

Когда вы работаете лишь с несколькими строками за раз, например, при вставке, обновлении, удалении или выборке одной строки по идентификатору, накладные расходы на дополнительные столбцы незначительны. SQL Server может нырнуть в эту одну строку и просто извлечь её, и поскольку она всё равно находится на одной странице размером 8 КБ, количество столбцов не влияет на операции с одной строкой.

Однако, когда вам нужно прочитать много строк, чем больше строк вы читаете, тем сильнее дополнительные столбцы влияют на накладные расходы операции.

Два дополнительных элемента управления при включённой автоматической коррекции планов

Автор: Erin Stellato (MICROSOFT), Two additional controls with Automatic Plan Correction enabled;

Несколько недель назад я опубликовала свой первый «Пятничный отзыв» о Хранилище запросов (Query Store), и один из ответов ссылался на хранимую процедуру, которую я раньше не использовала: sp_configure_automatic_tuning. Было высказано предположение, что эта хранимая процедура не документирована и работает не так, как ожидалось. Зная, как сильно я люблю Хранилище запросов, автоматическую коррекцию планов и документацию, я отправилась на поиски. Если вы не знакомы с этой хранимой процедурой, читайте дальше.

Диагностика конкуренции за tempdb

Автор: Paul Randal, The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention

Одна из самых распространённых проблем производительности, существующих в экземплярах SQL Server по всему миру, известна как конкуренция за tempdb. Что это означает? Конкуренция за tempdb относится к узкому месту для потоков, пытающихся получить доступ к страницам распределения, находящимся в памяти; это не связано с вводом-выводом.

Накопительный пакет обновления SQL Server 2022 CU26 - KB5093420

Описание: KB5093420

Скачать: SQLServer2022-KB5093420-x64.exe

Дата выпуска: 16.07.2026

SQL Server 2022 — Версия: 16.0.4265.3

Analysis Services — Версия: 16.0.43.252

Краткое описание изменений

• Добавлена более подробная информация об ошибках в журнал кластера Windows Server Failover Cluster, если ресурс группы доступности не может получить диагностические сведения о колонках.
• Добавлена поддержка удаления IP-адреса из прослушивателя группы доступности с помощью команды ALTER AVAILABILITY GROUP ... MODIFY LISTENER ... REMOVE IP.
• Исправлена уязвимость SQL-инъекции в хранимой процедуре sys.sp_MSforeachdb, позволяющая авторизованному злоумышленнику повысить привилегии через сеть.
• Исправлена проблема, из-за которой план обслуживания перестройки индекса переставал отвечать из-за длительного запроса.
• Исправлен сбой мониторинговых запросов с использованием sys.dm_exec_requests или sys.sysprocesses на вторичной реплике группы доступности (ошибки 976 или 978).
• Исправлена ошибка интерполяции в новом оценщике кардинальности для очень больших значений, из-за которой операция ALTER INDEX выбирала последовательный план.
• Удалена устаревшая криптографическая библиотека RSA32Lib в рамках модернизации шифрования.
• Исправлено нарушение доступа при выполнении ALTER PARTITION FUNCTION ... SPLIT RANGE для функции секционирования, используемой таблицей с identity-столбцом, на который ссылается кластеризованный индекс в схемно-привязанном представлении.
• Исправлено состояние «nonyielding scheduler», возникающее при записи некоторых ошибок в журнал ошибок SQL Server.
• Скорректирован коэффициент выборки для инкрементальной статистики, если последний коэффициент выборки был 100 % и в таблицу добавлено много новых строк.
• Улучшено управление памятью при компиляции запросов для индексов columnstore, что сокращает время компиляции.
• Исправлено состояние «nonyielding scheduler», возникающее при итерации sys.dm_db_index_operational_stats по большому количеству кэшированных куч или B-деревьев.

Накопительный пакет обновления SQL Server 2025 CU7 - KB5096981

Описание: KB5096981

Скачать: SQLServer2025-KB5096981-x64.exe

Дата выпуска: 16.07.2026

SQL Server 2025 — Версия: 17.0.4065.4

Analysis Services — Версия: 17.0.25.223

Краткое писание изменений

• Исправлен сбой мониторинговых запросов к вторичной реплике (ошибки 976/978) в группе доступности.
• Шифрование UCS переключено на AES-256 (вместо AES-128), если TLS не включён явно.
• Устранено состояние «non-yielding scheduler» при записи ошибки часового пояса в журнал ошибок.
• Добавлен флаг трассировки для включения TLS 1.3 (без правки реестра).
• Усилено шифрование диалогов Service Broker — теперь AES-256.
• Введено логическое ограничение для функции EDIT_DISTANCE, предотвращающее переполнение и DoS-атаки.
• Удалена поддержка устаревшего BinaryMessageFormatter (2000) в задаче Message Queue — устранена уязвимость десериализации.
• Исправлен вызов дампа при ALTER JSON INDEX REORGANIZE, если статистика существует во внутренней таблице JSON-индекса.
• Исправлен неверный расчёт смещения родительского узла, вызывавший повреждение JSON при JSON_MODIFY.
• Устранено повреждение данных и дамп-файл при операции слияния JSON_MODIFY.

Код для оценки потенциальной экономии пространства ключа кластеризации для каждой таблицы

Автор: Paul Randal, Code to list potential cluster key space savings per table

Чем больше ключ кластеризации в вашей таблице, тем больше пространства тратится впустую во всех строках некластерных индексов.

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

Вы можете модифицировать код по своему усмотрению. И я продолжаю использовать sp_msforeachdb, потому что это самый быстрый способ для меня написать код для вас, и это продолжает раздражать моего хорошего друга Аарона Бертрана (Aaron Bertrand) :-)

Наслаждайтесь!

Статистика ожиданий для одной операции

Автор: Paul Randal, Capturing wait stats for a single operation

Эта статья о настройке производительности, которая давно была в моём списке задач. Анализ статистики ожиданий — отличный способ изучить симптомы проблем с производительностью (см. мой каталог Wait Stats для получения дополнительной информации), но использование DMV sys.dm_os_wait_stats показывает всё, что происходит на сервере. Если вы хотите увидеть, какие ожидания возникают из-за одного запроса или операции в рабочей системе (например, влияние подсказок MAXDOP на количество и продолжительность ожиданий CXPACKET для запроса), то использование DMV обычно нецелесообразно — вам пришлось бы очистить статистику ожиданий и убедиться, что в системе не выполняется ничего, кроме исследуемого запроса/операции. Наиболее правильный способ сделать это — использовать расширенные события (Extended Events).

Структуры хранения #5 – XML-индексы

Автор: Hugo Kornelis, Storage structures 5 – XML indexes;

После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.

Оптимизация запросов: выражения в предложении WHERE, не допускающие поиска по индексу

Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions

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

Я подготовлю тестовый пример, чтобы показать, что я имею в виду.