Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)

Автор: Luca Biondi, SQL Server: No New Index. No Schema Changes. 10x Faster Queries – SQL Server Batch Mode on Rowstore Deep Dive!! Part 4!

Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).

Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.

Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.

Если вы пропустили предыдущую часть, вы можете прочитать её здесь:

👉 Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)

Но вот в чём поворот.

Начиная с SQL Server 2019, вам не всегда нужен колоночный индекс, чтобы получить производительность пакетного режима.

SQL Server может активировать пакетный режим для строчного хранения.

И иногда... как я сказал вам в начале этой статьи... ваш запрос становится в 5 или 10 раз быстрее без добавления ни одного индекса. Поэтому я предлагаю вам продолжить чтение...

Логические чтения не повторяемы на колоночных индексах (эх...)

Автор: Brent Ozar, Logical Reads Aren’t Repeatable on Columnstore Indexes. (sigh)

Иногда я действительно ненавижу свою работу.

Вечно, ВЕЧНО, я мог утверждать: «Когда вы измеряете производительность хранилища во время настройки индексов и запросов, вы всегда должны использовать логические чтения, а не физические, потому что логические чтения повторяемы, а физические — нет. Физические чтения могут меняться в зависимости от того, что находится в кэше, какие другие запросы выполняются в данный момент, от редакции вашего SQL Server и от того, используются ли упреждающие чтения. Логические чтения просто отражают точное количество прочитанных страниц, независимо от того, откуда пришли данные (с диска или из кэша), так что пока это число уменьшается, вы делаете свою работу хорошо».

Исправление безопасности для SQL Server 2025 CU2 - KB5077466

Описание: KB5077466

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

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

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

Исправление безопасности для SQL Server 2025 GDR - KB5077468

Описание: KB5077468

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

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

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

Исправление безопасности для SQL Server 2022 CU23 - KB5077464

Описание: KB5077464

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

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

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

Исправление безопасности для SQL Server 2022 GDR - KB5077465

Описание: KB5077465

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

Дата выпуска: 10.03.2026.

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

Исправление безопасности для SQL Server 2019 CU32 - KB5077469

Описание: KB5077469

Скачать: SQLServer2019-KB5077469-x64.exe

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

SQL Server 2019 — версия: 15.0.4460.4

Исправление безопасности для SQL Server 2019 GDR - KB5077470

Описание: KB5077470

Скачать: SQLServer2019-KB5077470-x64.exe

SQL Server 2019 — версия: 15.0.2160.4

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

Исправление безопасности для SQL Server 2017 CU31 - KB5077471

Описание: KB5077471

Скачать: SQLServer2017-KB5077471-x64.exe

SQL Server 2017 — версия: 14.0.3520.4

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

Исправление безопасности для SQL Server 2017 GDR - KB5077472

Описание: KB5077472

Скачать: SQLServer2017-KB5077472-x64.exe

SQL Server 2017 — версия: 14.0.2100.4

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

Исправление безопасности для SQL Server 2016 SP3 - KB5077474

SQL Server 2016 — версия: 13.0.6480.4

Описание: KB5077474

Скачать: SQLServer2016-KB5077474-x64.exe

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

Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)

Автор: Luca Biondi, SQL Server, Filtered Index vs Indexed View vs Columnstore Index! Part 3

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

Если вы пропустили Часть 2, вы можете прочитать её здесь:

👉 Фильтрованные индексы: сравнение производительности с примерами (Часть 2)

Сегодня мы добавляем в игру нового игрока.

Потому что, когда объём данных начинает расти… когда миллионы строк превращаются в десятки или сотни миллионов… мы получаем мощного нового союзника:

Колоночные индексы (Columnstore Indexes).

И это меняет всё.

Фильтрованные индексы: сравнение производительности с примерами (Часть 2)

Автор: Luca Biondi, Filtered Index vs Indexed View in SQL Server: Complete Performance Comparison with Real Examples

Эта статья является продолжением предыдущего глубокого погружения в настройку производительности SQL Server!

Если вы пропустили Часть 1, вы можете прочитать её здесь:

Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)

В первой статье мы проанализировали, как фильтрованные индексы могут кардинально сократить логические чтения и оптимизировать планы выполнения.

Сегодня мы углубляемся и сравниваем фильтрованный индекс с индексированным представлением, используя практические, воспроизводимые SQL-скрипты.

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

Анатомия задания очистки CDC в SQL Server (и как поддерживать его в рабочем состоянии)

Автор: Paul Ou Yang, Anatomy of a SQL Server CDC Cleanup Job (and How to Keep It Healthy)

Система отслеживания изменений данных (Change Data Capture, CDC) замечательна, пока не перестаёт ей быть. При высокой интенсивности изменений задание очистки CDC может начать отставать. Когда это происходит, таблицы изменений (Change Tables, CT) быстро разрастаются, а задание очистки может блокировать задание записи (capture job), что, в свою очередь, может задерживать или останавливать нижестоящие системы-потребители.

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

Почему LOB-колонки делают SHRINK очень медленным

Автор: Paul Randal, Why LOB data makes shrink run slooooowly (T-SQL Tuesday #006)

[Примечание от января 2015: Всё, что написано в этом посте, по-прежнему актуально для SQL Server 2012 и 2014.]

Тема этой статьи — LOB-данные, поэтому я немного отклонюсь от темы и объясню, почему LOB-данные делают производительность сжатия (shrink) действительно отвратительной (это технический термин :-).

Устранение ошибок включения CDC — Часть 2

Автор: Brass Contributor, Troubleshooting CDC enabling failure - Part 2

В предыдущей статье блога я рассказывал о сбое CDC из-за отключённого пользователя guest в MSDB. Тогда же мой заказчик столкнулся и с другой проблемой:

Msg 22832, Level 16, State 1, Procedure sp_cdc_enable_table_internal, Line 622

Could not update the metadata that indicates table [dbo].[Table_Name] is enabled 

for Change Data Capture. The failure occurred when executing the command 

'insert into [cdc].[change_tables]'. The error returned was 515: 

'Cannot insert the value NULL into column 'has_drop_pending', 

table 'LLCProduction.cdc.change_tables'; column does not allow nulls. 

INSERT fails.'. Use the action and error to determine the cause of the failure 

and resubmit the request.

Они обошли её, включив параметр ANSI_NULL_DEFAULT на уровне базы данных:

ALTER DATABASE DB_Name SET ANSI_NULL_DEFAULT ON;

После этого CDC включился успешно.

Вопрос в том, какова первопричина этой проблемы и как мы можем избежать её в будущем?

Устранение ошибок включения CDC — Часть 1

Автор: Brass Contributor, Troubleshooting CDC enabling failure - Part 1

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

Проблема:

В выходные заказчик попытался перенести некоторые изменения на производственный сервер. При попытке включить CDC на производственном сервере сначала возникла ошибка безопасности:

#1: Ошибка безопасности:

Msg 22832, Level 16, State 1, Procedure sp_cdc_enable_table_internal, Line 622

Could not update the metadata that indicates table [dbo].[Table_Name] is enabled for 

Change Data Capture. The failure occurred when executing the command 

'[sys].[sp_cdc_add_job] @job_type = N'capture''. 

The error returned was 916: 'The server principal "S-1-9-3-1293060401-1231192665-3834407059-1208013724." 

is not able to access the database "msdb" under the current security context.'. 

Use the action and error to determine the cause of the failure and resubmit the request

Безопасная очистка потерянных записей в Change Tracking (часть 2)

Автор: Mohamed_Baioumy_MSFT, Part 2: Safely Cleaning Orphaned Records in Change Tracking Side Tables

Область применения: База данных SQL Azure (с включенным отслеживанием изменений)

Краткое повторение (Часть 1)

В Части 1 мы рассмотрели, как обнаружить ""Orphaned записи во вспомогательных таблицах отслеживания изменений — строки, чей sys_change_xdes_id больше не имеет соответствующей записи транзакции в таблице фиксации (sys.syscommittab). Эта ситуация часто приводит к неожиданному росту размера отслеживания изменений и симптомам "stuck cleanup", потому что данные сопоставления, необходимые для нормальной очистки, отсутствуют.

Ссылка на Часть 1: Выявление потерянных записей в Change Tracking (часть 1)

Почему нужна Часть 2

Распространенный "корневой шаблон", который мы наблюдаем на практике:

• Очистка вспомогательных таблиц пытается удалить устаревшие метаданные
• Некоторые удаления из вспомогательных таблиц завершаются сбоем (блокировки, тайм-ауты, ошибки)
• Очистка таблицы фиксации всё равно выполняется (или пользовательский рабочий процесс удаляет данные из таблицы фиксации без проверки удаления из вспомогательных таблиц)
• Оставшиеся строки вспомогательных таблиц теперь ссылаются на значения xdes_id, которые больше не существуют в sys.syscommittab → образуются потерянные записи

В документации Microsoft Learn также подчеркивается, что очистка syscommittab зависит от очистки вспомогательных таблиц — очистка таблицы фиксации должна происходить только после очистки вспомогательных таблиц.

Этот скрипт из Части 2 сосредоточен на удалении потерянных, осиротевших строк из вспомогательных таблиц (и не затрагивает sys.syscommittab), чтобы логика очистки могла снова стабилизироваться.

Выявление потерянных записей в Change Tracking (часть 1)

Автор: Mohamed_Baioumy_MSFT, Identifying Orphaned Records in Change Tracking Side Tables (Read‑Only Health Check)

Когда в SQL Server включено отслеживание изменений (CT, Change Tracking), компонент ядра СУБД сохраняет облегчённые метаданные об изменениях, чтобы приложения могли запрашивать: "что изменилось, начиная с версии X?". Внутреннее устройство CT подразумевает наличие:

• Вспомогательной таблицы для каждой отслеживаемой пользовательской таблицы. В ней хранятся метаданные изменений на уровне строк (включая идентификатор транзакции).
• Таблицы фиксации (commit table), в которой хранятся зафиксированные транзакции, затронувшие любую таблицу с включенным отслеживанием изменений. Динамическое административное представление (DMV) sys.dm_tran_commit_table отображает объединение частей этой таблицы фиксации, находящихся в памяти и на диске.

При нормальной работе очистка CT удаляет устаревшие строки из вспомогательных таблиц, а затем — соответствующие более старые строки из таблицы фиксации, основываясь на настроенном периоде хранения. Внутренняя логика очистки использует "безопасную точку очистки", получаемую из настроенного периода хранения, и сопоставляет это астрономическое время с версией CT с помощью системной хранимой процедуры sys.sp_changetracking_time_to_csn.

Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)

Автор: Luca Biondi, SQL Server Performance Tuning: How Filtered Indexes Drastically Improve Query Performance

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

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

В этой статье мы проанализируем, как фильтрованные индексы в SQL Server могут уменьшить ввод-вывод, оптимизировать планы выполнения и значительно повысить производительность OLTP.