Настройка производительности CDC

Автор: Штеффен Краузе (Steffen Krause)

Соавторы: Санджай Мишра (Sanjay Mishra), Гопал Ашок (Gopal Ashok), Грег Ивкофф (Greg Yvkoff), Жуй Ван (Rui Wang)

Технические рецензенты: Бурзин Патель (Burzin Patel), Денни Ли (Denny Lee), Гленн Берри (Glenn Berry, MVP SQL Server), Джозеф Сак (Joseph Sack), Линдси Аллен (Lindsey Allen), Майкл Редман (Michael Redman), Майк Рутрафф (Mike Ruthruff), Пол С. Рэндал (Paul S. Randal, SQLskills.com), Tuning the Performance of Change Data Capture in SQL Server 2008

Краткое содержание: Отслеживание изменений данных (Change Data Capture, CDC) — это новая функция в SQL Server, которая предоставляет простой способ отслеживания изменений данных в наборе таблиц базы данных для последующей передачи этих изменений во вторую систему, например, в хранилище данных. В этом документе содержатся рекомендации по настройке параметров отслеживания изменений данных для максимальной производительности захвата данных при минимальном влиянии на производительность производственной нагрузки. Область действия этого документа ограничена захватом изменяемых данных и процессом очистки. Запрос изменённых данных не входит в область действия данного технического документа.

Форматирование T-SQL запросов в SSMS 22.7

Автор: Chad Callihan , SQL Formatting in SSMS 22.7

Форматирование кода может быть деликатной темой. Иногда существуют чёткие правила, определяющие правильное и неправильное, а иногда их нет. Пробелы против табуляции, что выбрать?

Как ни удивительно, но в SQL Server Management Studio никогда не было встроенного средства форматирования SQL. Пользователям всегда приходилось пользоваться сторонними инструментами или форматировать вручную. Но с выходом последней версии SSMS 22.7 форматирование SQL наконец стало встроенной функцией.

Давайте рассмотрим несколько примеров и посмотрим, как она работает.

Могут ли ключи кластерного индекса с типом GUID вызывать фрагментацию некластерных индексов?

Автор: Paul Randal, Can GUID cluster keys cause non-clustered index fragmentation?

На встрече пользовательской группы я потратил некоторое время на объяснение того, как GUID могут вызывать фрагментацию как в кластерных, так и в некластерных индексах, даже если GUID специально не включён в ключ некластерного индекса. GUID — это, по сути, случайные значения (псевдослучайные в диапазонах, если генерируются с помощью NEWSEQUENTIALID), которые также уникальны. Их уникальность делает их привлекательными для многих разработчиков в качестве значения ключа, не понимая при этом того хаоса, который они могут вызвать в производственной среде с точки зрения фрагментации и низкой производительности запросов.

Насколько сложно выбрать правильные некластерные индексы?

Автор: Paul Randal, How hard is it to pick the right non-clustered indexes?

На собрании группы разработчиков .NET в Редмонде, и во время того, как Кимберли рассказывала о пропущенных и лишних индексах, возник следующий вопрос:

«Какой некластерный индекс лучше всего использовать для запроса с условием WHERE lastname = 'Randal' AND firstname = 'Paul' AND middleinitial = 'S'?»

Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)

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

Описание: KB5093421

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

Дата выпуска: 17 июня 2026 г.

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

И вот однажды RCSI сделал результаты запросов более точными

Автор: Brent Ozar, And Then There Was The Time RCSI Actually Made Query Results More Accurate

Обычно, когда я рассказываю людям об оптимистичных уровнях изоляции SQL Server — Read Committed Snapshot Isolation (RCSI) и Snapshot Isolation (SI) — мне приходится произносить небольшую речь о том, что им нужно тестировать свои запросы, потому что результаты могут измениться.

Однако недавно я работал с клиентом, который получал неверные результаты запросов при использовании пессимистичного уровня изоляции по умолчанию — и мы переключились на RCSI, чтобы это исправить! Я не буду объяснять здесь RCSI или SI — используйте ссылку выше для ознакомления с основами — вместо этого я сосредоточусь на демонстрационном скрипте, который я написал, чтобы показать проблему, с которой они столкнулись, и то, как RCSI её решил.

Новое в SQL Server 2025: функции кодирования и декодирования Base64

Автор: Leonard Lobel, Base64 Encoding and Decoding in SQL Server 2025 and Azure SQL Database

SQL Server 2025 добавляет встроенную поддержку кодирования и декодирования Base64 с помощью двух T-SQL-функций: BASE64_ENCODE и BASE64_DECODE. Эти функции значительно упрощают преобразование двоичных данных в дружественные к тексту представления и обратное преобразование строк в двоичные данные, когда это необходимо.

Это полезно во многих повседневных сценариях: встраивание двоичного содержимого в JSON, создание URL данных для HTML, передача двоичных полезных нагрузок через текстовые протоколы и создание безопасных для URL токенов. Раньше разработчикам часто приходилось полагаться на XML-трюки, код на стороне приложения, CLR-функции или собственную логику преобразования. Теперь эта функциональность доступна непосредственно в T-SQL.

Важно: Base64 — это формат кодирования, а не механизм шифрования. Он делает двоичные данные дружественными к тексту, но не обеспечивает безопасность или скрытие основных данных.

Представляем расширение StatisticsParser для SSMS

Автор: Brent Ozar, Announcing the SSMS StatisticsParser Extension

Если вы много занимаетесь настройкой запросов, то, вероятно, сталкивались с StatisticsParser.com от Ричи Рамп (Richie Rump). Теперь пользоваться им стало ещё проще.

Скачайте и установите расширение, затем выполните ваш запрос с включёнными SET STATISTICS IO, TIME ON, и после завершения щёлкните правой кнопкой мыши в окне запроса и выберите Parse Statistics.

Обходим шторм компиляций стороной

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (III) in 45 Seconds

Вы когда-нибудь задумывались, почему ваш ЦП достигает 100% при низком объёме запросов? В этой статье я разберу механизм «Штормов компиляции» (Compilation Storms) и покажу, как обнаружить узкие места типа SOS_CACHESTORE менее чем за минуту.

В двух словах

• Стоимость компиляции (Compilation Cost): Такты ЦП тратятся впустую, когда SQL Server выполняет «Полную оптимизацию» (Full Optimization) многократно.
• Тривиальные планы (Trivial Plans): Быстрый путь к выполнению, который пропускает оптимизацию на основе стоимости для простых запросов.
• Триггеры перекомпиляции (Recompilation Triggers): Плохая статистика и изменения схемы (DDL) являются основными подозреваемыми в нестабильности кэша.
• Предупреждение о спинблокировке (Spinlock Warning): Высокое время ожидания SOS_CACHESTORE означает интенсивную конкуренцию за кэш планов.

Управление высококонкурентной средой SQL Server — это игра на миллиметры. Мы часто говорим о «быстрых запросах», но редко говорим о налоге, который движок платит до того, как запрос вообще начнётся: о компиляции. Когда ваш кэш планов нестабилен, SQL Server входит в «Шторм компиляции», превращая ваши высококлассные ЦП в дорогие обогреватели. Давайте заглянем под капот.

Поддержка регулярных выражений для LOB-типов в T-SQL — доступно в SQL Server 2025 CU5

Автор: abhimantiwari, Regex support for LOB types in T-SQL—available in Azure SQL & SQL Server 2025

Краткий обзор. Собственные функции регулярных выражений (regex) в T-SQL теперь принимают входные данные типа varchar(max) и nvarchar(max) размером до 2 МБ во всех семи функциях регулярных выражений, включая две табличные функции (REGEXP_MATCHES и REGEXP_SPLIT_TO_TABLE). Эта возможность поставляется в SQL Server 2025 CU5. Вам больше не нужно разбивать файлы журналов, HTML-документы или большие JSON-нагрузки на 8000-байтовые фрагменты только для того, чтобы выполнить сопоставление с шаблоном.

Выметаем ядовитые планы из кэша SQL Server

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (II) in 45 Seconds

Вы исправили ad-hoc запросы, но ваш сервер всё ещё «колбасит»? В этой статье я расскажу, почему даже идеальная параметризация может привести к «токсичности повторного использования» (reuse toxicity) и массовым скачкам ЦП.

В двух словах

• Параметризованное засорение (Parameterized Pollution): Засорение кэша — это не только «слишком много планов», но и повторно используемый «неправильный план». 
• Токсичность повторного использования (Reuse Toxicity): План, оптимизированный для одной строки, принудительно применяется к набору из миллиона строк, убивая производительность.
• Нестабильность планов (Plan Instability): Резкие колебания между min_worker_time и max_worker_time указывают на войну, вызванную Sniffing'ом параметров.
• Решение: Используйте Query Store, идентификацию по query_hash и оптимизацию PSP в SQL Server 2022.

В предыдущей части этой серии мы очистили кэш от «мусорных» планов. Но горькая правда в том, что чистый код не гарантирует чистый кэш. Даже когда ваше приложение на 100% параметризовано, SQL Server всё ещё может страдать от другого вида засорения — логической токсичности. Это происходит, когда движок повторно использует неоптимальный план выполнения, потому что во время компиляции он «унюхал» (sniffed) непредставительный параметр.

Проверка кэша SQL Server на засорение одноразовыми планами

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (I) in 45 Seconds

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

В двух словах

• Загрязнение кэша планов (Plan Cache Pollution) происходит, когда непараметризованные запросы создают тысячи бесполезных одноразовых планов выполнения. 
• Вымывание памяти (Memory Starvation): Эти планы крадут пространство у буферного пула, вытесняя данные из памяти и увеличивая ввод-вывод. 
• Исправление: Используйте параметризацию, sp_executesql или включите настройку «Optimize for Ad Hoc Workloads». 
• SQL-запрос «Wow!»: Определите, какие именно ad-hoc запросы прямо сейчас засоряют ваш кэш. 

За 25 лет настройки производительности я видел, как миллионы долларов, вложенных в оборудование, оказывались бесполезными из-за плохих привычек кодирования. Один из самых распространённых молчаливых убийц — засорение кэша планов. Это технический эквивалент заполнения библиотеки идентичными книгами, в которых меняется только одна страница. Каждый раз, когда ваше приложение отправляет запрос вроде WHERE Id = 1, а затем WHERE Id = 2 без параметризации, SQL Server обрабатывает их как совершенно новую логику.

Адаптивные соединения (Adaptive Joins) и распределение памяти в SQL Server

Автор: Kendra Little, Adaptive Joins and Memory Grants in SQL Server

Адаптивные соединения (adaptive joins) позволяют оптимизатору выбирать между хэш-соединением (Hash Join) и соединением вложенными циклами (Nested Loop join) во время выполнения, что может быть фантастически полезно для производительности, когда оценки количества строк могут варьироваться. Недавно, когда Эрик Дарлинг (Erik Darling) преподавал двухдневный курс по T-SQL на PASS Community Data Summit, один из студентов спросил, почему план запроса, в котором адаптивное соединение во время выполнения использовало вложенные циклы, всё равно получило большое распределение памяти (memory grant).

Я не помнила ответа на этот вопрос, но замечательная вещь в совместном преподавании в том, что Эрик его знал: адаптивные соединения всегда начинают выполняться как хэш-соединения, а это означает, что они должны получить распределение памяти заранее. Даже если в итоге запрос переключается на вложенные циклы во время выполнения, это распределение памяти уже было выделено. Это имеет реальные последствия для использования памяти, особенно в средах с высокой конкурентностью (high-concurrency environments).

Чего ждёт SOS_SCHEDULER_YIELD в SQL Server: причины и реакция

Автор: Steve Stedman, Decoding SOS_SCHEDULER_YIELD Wait Type in SQL Server: Causes and Solutions

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

По своей сути, SOS_SCHEDULER_YIELD отражает давление на ресурсы ЦП, поскольку задачи выстраиваются в очередь для выполнения. Хотя случайные уступки ожидаемы в загруженной среде, чрезмерные ожидания могут указывать на конкуренцию за ЦП, плохо оптимизированные запросы или даже аппаратные ограничения. Определение того, является ли этот тип ожидания симптомом более серьёзной проблемы, требует системного подхода к мониторингу и анализу, что в конечном итоге может привести к значительному повышению производительности.

В этой статье мы разберём тип ожидания SOS_SCHEDULER_YIELD, изучим его причины и то, когда он становится проблемой для вашей среды SQL Server. Мы проведём вас через методы диагностики, чтобы выявить корневые проблемы, и предоставим практические решения для снижения их влияния. Будь вы администратором баз данных (DBA) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

Неудобная правда о скалярных функциях

Автор: Luca Biondi, The Dangerous Truth About Scalar Functions in 45 Seconds

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

В двух словах

• Скалярные UDF принудительно вызывают покадровое выполнение (RBAR — Row-By-Agonizing-Row): они обходят мощные алгоритмы оптимизатора, основанные на работе с наборами данных. 
• Подавление параллелизма (Parallelism): Традиционные скалярные функции заставляют весь ваш запрос выполняться в одном потоке. 
• Скрытые затраты: Планы выполнения часто показывают стоимость UDF как 0%, маскируя огромные накладные расходы на ЦП. 
• Исправление: Используйте встроенные табличные функции (Inline Table-Valued Functions, iTVF) или функцию встраивания скалярных функций (Scalar Inlining), появившуюся в SQL Server 2019+. 

Новая официальная документация о принудительной параметризации (Forced Parameterization)

Автор: Brent Ozar, New Official Documentation on Forced Parameterization

Я обожаю хорошую документацию.

Много лет я указывал людям на документацию SQL Server 2008 о принудительной параметризации (Forced Parameterization) — действительно полезном инструменте для уменьшения раздувания кэша планов, получения более точных переиспользуемых планов запросов и включения функций интеллектуальной обработки запросов (Intelligent Query Processing) SQL Server 2019 и 2022, многие из которых полагаются на один и тот же текст запроса, поступающий повторно с течением времени, чтобы настроить его. Однако эта документация была довольно скудной.

"Подводные камни" неявных преобразований

Автор: Luca Biondi, The Hidden Cost of Implicit Conversions in 45 Seconds

Неявные преобразования — это молчаливые убийцы производительности, которые превращают молниеносные поиск по индексу (Index Seek) в мучительно медленные просмотры индекса (Index Scan). В этой статье я
покажу вам, как обнаружить их за 45 секунд и вернуть ваши такты ЦП!

В двух словах

• Убийство SARGability: Неявные преобразования не позволяют SQL Server эффективно использовать поиск по индексу. 
• Накладные расходы на ЦП: Преобразование каждой строки в таблице во время сравнения значительно увеличивает использование ЦП. 
• Старшинство типов данных (Data Type Precedence): SQL Server всегда преобразует тип с более низким приоритетом в тип с более высоким. 
• Исправление: Согласуйте типы данных столбца и параметра или используйте явное приведение типов в правильном направлении. 

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

Автор: 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, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.