Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)
Мы всё ещё говорим о пакетном режиме, потому что понимание того, когда он работает, так же важно, как и знание того, как его принудительно включить.
Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.
Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!
Предыдущая статья: Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)
Давайте пристально изучим Actual Execution Plan, и углубимся в изучение пакетного режима для строчного хранения.
Описание: KB5080999
Скачать: SQLServer2022-KB5080999-x64.exe
Дата выпуска: 12 марта 2026 г.
SQL Server 2022 — Версия: 16.0.4245.2
Описание: KB5077896
Скачать: SQLServer2025-KB5077896-x64.exe
Дата выпуска: 12 марта 2026 г.
SQL Server 2025 — Версия: 17.0.4025.3
Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).
Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.
Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.
Если вы пропустили предыдущую часть, вы можете прочитать её здесь:
Но вот в чём поворот.
Начиная с SQL Server 2019, вам не всегда нужен колоночный индекс, чтобы получить производительность пакетного режима.
SQL Server может активировать пакетный режим для строчного хранения.
И иногда... как я сказал вам в начале этой статьи... ваш запрос становится в 5 или 10 раз быстрее без добавления ни одного индекса. Поэтому я предлагаю вам продолжить чтение...
Иногда я действительно ненавижу свою работу.
Вечно, ВЕЧНО, я мог утверждать: «Когда вы измеряете производительность хранилища во время настройки индексов и запросов, вы всегда должны использовать логические чтения, а не физические, потому что логические чтения повторяемы, а физические — нет. Физические чтения могут меняться в зависимости от того, что находится в кэше, какие другие запросы выполняются в данный момент, от редакции вашего SQL Server и от того, используются ли упреждающие чтения. Логические чтения просто отражают точное количество прочитанных страниц, независимо от того, откуда пришли данные (с диска или из кэша), так что пока это число уменьшается, вы делаете свою работу хорошо».
Описание: KB5077466
Скачать: SQLServer2025-KB5077466-x64.exe
Дата выпуска: 10.03.2026
SQL Server 2022 — Версия: 17.0.4020.2
Описание: KB5077468
Скачать: SQLServer2025-KB5077468-x64.exe
Дата выпуска: 10.03.2026
SQL Server 2022 — Версия: 17.0.1105.2
Описание: KB5077464
Скачать: SQLServer2022-KB5077464-x64.exe
Дата выпуска: 10.03.2026
SQL Server 2022 — Версия: 16.0.4240.4
Описание: KB5077465
Скачать: SQLServer2022-KB5077465-x64.exe
Дата выпуска: 10.03.2026.
SQL Server 2022 — Версия: 16.0.1170.5
Описание: KB5077469
Скачать: SQLServer2019-KB5077469-x64.exe
Дата выпуска: 10.03.2026
SQL Server 2019 — версия: 15.0.4460.4
Описание: KB5077470
Скачать: SQLServer2019-KB5077470-x64.exe
SQL Server 2019 — версия: 15.0.2160.4
Дата выпуска: 10.03.2026
Скачать: SQLServer2017-KB5077471-x64.exe
SQL Server 2017 — версия: 14.0.3520.4Дата выпуска: 10.03.2026
Скачать: SQLServer2017-KB5077472-x64.exe
SQL Server 2017 — версия: 14.0.2100.4Дата выпуска: 10.03.2026
Описание: KB5077474
Скачать: SQLServer2016-KB5077474-x64.exe
Дата выпуска: 10.03.2026
В предыдущих статьях мы сравнили фильтрованные индексы и индексированные представления, поняв, в каких случаях каждый из них проявляет себя наилучшим образом.
Если вы пропустили Часть 2, вы можете прочитать её здесь:
👉 Фильтрованные индексы: сравнение производительности с примерами (Часть 2)
Сегодня мы добавляем в игру нового игрока.
Потому что, когда объём данных начинает расти… когда миллионы строк превращаются в десятки или сотни миллионов… мы получаем мощного нового союзника:
Колоночные индексы (Columnstore Indexes).
И это меняет всё.
Эта статья является продолжением предыдущего глубокого погружения в настройку производительности SQL Server!
Если вы пропустили Часть 1, вы можете прочитать её здесь:
Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)
В первой статье мы проанализировали, как фильтрованные индексы могут кардинально сократить логические чтения и оптимизировать планы выполнения.
Сегодня мы углубляемся и сравниваем фильтрованный индекс с индексированным представлением, используя практические, воспроизводимые SQL-скрипты.
Вы найдёте конкретные сценарии, которые сможете протестировать в своей собственной лаборатории — потому что настройка производительности — это не теория, это экспериментирование.
Система отслеживания изменений данных (Change Data Capture, CDC) замечательна, пока не перестаёт ей быть. При высокой интенсивности изменений задание очистки CDC может начать отставать. Когда это происходит, таблицы изменений (Change Tables, CT) быстро разрастаются, а задание очистки может блокировать задание записи (capture job), что, в свою очередь, может задерживать или останавливать нижестоящие системы-потребители.
Эта статья объясняет: как быстро оценить рост таблиц изменений, как задание очистки на самом деле удаляет строки и три основных «рычага» настройки для поддержания стабильности CDC.
[Примечание от января 2015: Всё, что написано в этом посте, по-прежнему актуально для SQL Server 2012 и 2014.]
Тема этой статьи — LOB-данные, поэтому я немного отклонюсь от темы и объясню, почему LOB-данные делают производительность сжатия (shrink) действительно отвратительной (это технический термин :-).
В предыдущей статье блога я рассказывал о сбое 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 enabledfor 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 failureand resubmit the request.
Они обошли её, включив параметр ANSI_NULL_DEFAULT на уровне базы данных:
ALTER DATABASE DB_Name SET ANSI_NULL_DEFAULT ON;После этого CDC включился успешно.
Вопрос в том, какова первопричина этой проблемы и как мы можем избежать её в будущем?