Любопытный случай периодического сбоя запроса к крошечной таблице

Автор: Paul Randal, The Curious Case of… occasional query failure on a tiny table

Это случай, произошедший в прошлом году в системе одного клиента: иногда обычный запрос к крошечной таблице, казалось, «зависал», и его приходилось убивать и запускать заново. В чём же дело?

Рассматриваемая таблица содержала всего несколько миллионов строк данных с максимальным размером строки 60 байт, и запрос обычно выполнялся за несколько секунд, но иногда он «зависал» и либо его приходилось убивать, либо он выполнялся десятки минут. Диагностические средства, запущенные во время возникновения проблемы, не показывали каких-либо необычных ожиданий, давления на сервер не было, а план запроса, генерируемый при долгом выполнении, был практически таким же.

Оптимизация базы данных для нерегламентированных запросов

Автор: Joe Sack, Database scoped optimizing for ad hoc workloads

SQL Server предоставляет параметр оптимизации для нерегламентированных рабочих нагрузок (ad-hoc workloads), действующий в рамках всего сервера, который используется для уменьшения объёма памяти, занимаемого одиночными ad-hoc пакетами и связанными с ними планами. Когда этот параметр включён на уровне экземпляра SQL Server, при первом выполнении пакета ad-hoc для любой базы данных на экземпляре сохраняется «заглушка» скомпилированного плана с уменьшенным потреблением памяти. Эта опция сервера OPTIMIZE_FOR_AD_HOC_WORKLOADS доступна начиная с SQL Server 2019, и имет область действия на уровне базы данных.

Большое количество планов выполнения для одного запроса

Автор: Jose_Manuel_Jurado, Lesson Learned #494: High number of Executions Plans for a Single Query

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

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

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

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

Принудительные планы в SQL Server перезаписывают хэш запроса

Автор: Paul White, SQL Server Forced Plans Overwite the Query Hash

Если вы «принудительно» задаёте план, любым методом, включая руководство планом (Plan Guides), хранилище запросов (Query Store) и автоматическое исправление плана (Automatic Plan Correction), результирующий план будет иметь свой query_hash перезаписанным значением query_plan_hash.

Другими словами, хэш плана и хэш плана запроса получат значение хэша плана запроса. Реальное значение хэша запроса просто теряется. 🤦

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

Автоматическое обновление статистики не всегда аннулирует кешированные планы выполнения

Автор: Brent Ozar, Automatic Stats Updates Don’t Always Invalidate Cached Plans

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

Однако обновление статистики, созданной системой, не обязательно приводит к повторной компиляции планов.

Это действительно странный крайний случай, и вы, вероятно, никогда с ним не столкнётесь, но я сталкиваюсь с ним на каждом занятии, которое провожу. Я каждый раз мимоходом упоминаю об этом в классе и даже не обращаю на это особого внимания. Однако недавно студент спросил меня: «Это где-нибудь задокументировано?», и я подумал, э-э, может быть, но я не уверен, так что лучше задокументировать это здесь, в старом добром блоге.

Сериализация операций удаления из кластерных columnstore-индексов

Автор: Aaron Bertrand , Serializing Deletes From Clustered Columnstore Indexes

На Stack Overflow у нас есть несколько таблиц с кластерными columnstore-индексами, которые отлично работают для большей части нашей нагрузки. Но мы недавно столкнулись с ситуацией, когда «идеальные штормы» — несколько процессов, пытающихся одновременно удалить данные из одного columnstore-индекса — перегружали процессор, поскольку они все запускались с высокой степенью параллелизма и боролись за завершение своей операции.

Обновление до SQL Server 2025: три извлечённых урока

Автор: Aaron Bertrand , Upgrading to SQL Server 2025: Three Lessons Learned

Мы недавно обновили несколько систем до SQL Server 2025. Само обновление ядра прошло гладко, но в наших контурах предварительной подготовки, когда мы планировали переход в прод, возникли три неожиданные проблемы. Ни одна из них не помешала завершению обновления, но все три могли легко сорвать в остальном плавное обновление на месте до SQL Server 2025. Что это были за проблемы и как можно избежать их возникновения?

Тестирование ограничений tempdb в Resource Governor SQL Server 2025 с запросом, вызывающим переполнение на терабайт

Автор: Kendra Little, Testing SQL Server 2025 Resource Governor tempdb Limits with a Query that Spills a Terabyte

SQL Server 2025 представляет новую возможность Resource Governor для управления использованием tempdb, а также делает Resource Governor доступным в Standard Edition.

Мне стало интересно: может ли новая функция tempdb в Resource Governor помочь сдержать запросы, которые не используют временные таблицы, но вызывают массовое переполнение данных в tempdb? В документации говорится «да», но я всегда предпочитаю получить практический опыт, когда это возможно.

У меня есть ужасный запрос, который «переливается через край», как автомат с мягким мороженым, объявивший войну. Давайте протестируем новые функции управления tempdb в SQL Server 2025.

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

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

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

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

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

Новое в SQL Server 2025: Always On, AG и FCI

Автор: David Levy, Announcing General Availability of the mssql-python Driver

Дата релиза SQL Server 2025: 18 ноября 2025 г.

В этой статье собран подробный обзор нововведений Always On в SQL Server 2025: быстрый фейловер при устойчивых проблемах, ускорение синхронизации при переключениях, улучшения отказоустойчивости после кратковременной потери кворума, усиление безопасности соединений (TLS 1.3 и TDS 8.0), гибкость управления прослушивателями и маршрутизацией трафика, а также поддержка полноценных резервных копий на вторичных репликах. Материал ориентирован на проектирование, внедрение и эксплуатацию HA/DR решений. Подготовлено с помощью GPT5.

Потребление памяти запросами в SQL Server 2025

Автор: SQLYARD, SQL Query Memory Consumption in SQL Server 2025

Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.

В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.

Малоиспользуемые индексы в группах доступности – Часть 2

Автор: Aaron Bertrand , Managing Underused Indexes in SQL Server Availability Groups – Part 2

В первой части статьи «Малоиспользуемые индексы в группах доступности – Часть 1» я показал, как с помощью динамического SQL собрать статистику использования индексов для заданной таблицы со всех реплик в группе доступности. Знать использование по всем нагрузкам, безусловно, лучше, чем смотреть только на первичную или на одну вторичную. Но что если я хочу принимать ещё более взвешенные решения, добавив к выводу количество строк, размер и столбцы индексов?

Малоиспользуемые индексы в группах доступности – Часть 1

Автор: Aaron Bertrand , Managing Underused Indexes in SQL Server Availability Groups – Part 1
В рамках оптимизации производительности я оцениваю использование индексов на множестве экземпляров и в разных базах данных. Часто обнаруживается, что некоторые индексы используются нечасто или, по крайней мере на первый взгляд, кажутся неиспользуемыми. Поскольку мы используем группы доступности (AG), разные рабочие нагрузки выполняются на репликах в разных ролях. Все операции записи, разумеется, происходят на первичной. Однако некоторые запросы выполняются только на вторичных репликах для чтения (либо за счёт маршрутизации чтения, либо потому, что отдельные процессы вручную направляются на конкретные вторичные, либо же и то и другое). К сожалению, статистика использования индексов нигде не агрегируется по всем репликам сразу. Это значит, что анализ только первичной реплики даёт неполную картину. Как убедиться, что я учитываю активность индексов везде, а не только на первичной?

Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY

Автор: Chandan Shukla, Unlocking High-Concurrency Inserts in SQL Server with OPTIMIZE_FOR_SEQUENTIAL_KEY

Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.

Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.

Оптимизация чувствительных к параметрам планов исполнения в 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.

Страсти по SQL Server 2025: ускоренное восстановление базы данных не исправляет проблему NOLOCK!!!

Автор: Brent Ozar, No, Accelerated Database Recovery Doesn’t Fix NOLOCK

Я никогда не видел в T-SQL такой фразы, которую так же любят использовать, как NOLOCK. Мне постоянно кажется, что я написал уже достаточно публикаций об этом, но вот недавно клиент высказал новую идею:

Мы используем Accelerated Database Recovery в SQL Server 2022, который хранит версии строк внутри таблицы. К тому же мы не используем транзакции — наши операции вставки, обновления и удаления выполняются над одной таблицей за раз, а ваши демонстрации всегда используют транзакции, поэтому нас это не затрагивает.

Новое в SQL Server 2025: Кардинальность и REGEXP_LIKE

Автор: Louis Davidson, Cardinality and REGEXP_LIKE

Я читал пост Брента Озара о регулярных выражениях в SQL Server 2025 (T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited) и о том, почему они работают так, как работают. В комментариях кто-то упомянул несколько подсказок (hints), которые якобы должны улучшить ситуацию. О них написано немного, поэтому я решил сам проверить, как они себя ведут. Речь идёт о: ASSUME_FIXED_MAX_SELECTIVITY_FOR_REGEXP и ASSUME_FIXED_MIN_SELECTIVITY_FOR_REGEXP. Они работают, корректируя ожидаемое количество строк, возвращаемых условием с оператором REGEXP.

T-SQL получил Regex в SQL Server 2025. Но не спешите радоваться

Автор: Brent Ozar. T-SQL Has Regex in SQL Server 2025. Don’t Get Too Excited

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

Этот пост не про сложность, а про производительность regex в Azure SQL DB и SQL Server 2025.

Regex как Everclear

Everclear — это марка алкоголя. Звучит заманчиво: без запаха, вкуса и цвета. Но на самом деле это 95% чистого спирта, настолько крепкий, что во многих штатах США его просто запретили. Даже в Неваде, где разрешены казино, оружие и марихуана.

Что нового для columnstore-индексов в SQL Server 2025

Автор: SQLYARD. What’s New for Columnstore Indexes in SQL Server 2025

Columnstore-индексы прошли длинный путь с момента появления в SQL Server 2012. В каждом новом выпуске они становились быстрее, гибче и удобнее в обслуживании. В SQL Server 2025 Microsoft добавила очередную порцию улучшений — теперь упор сделан на производительность и непрерывность работы.

Три ключевых изменения

• Упорядоченные некластеризованные columnstore-индексы
• Онлайн-перестроение упорядоченных columnstore-индексов
• Более эффективный shrink при наличии столбцов с MAX-типами