Автор: Paul Randal, The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention
Одна из самых распространённых проблем производительности, существующих в экземплярах SQL Server по всему миру, известна как конкуренция за tempdb. Что это означает? Конкуренция за tempdb относится к узкому месту для потоков, пытающихся получить доступ к страницам распределения, находящимся в памяти; это не связано с вводом-выводом.
Описание: KB5093420
Скачать: SQLServer2022-KB5093420-x64.exe
Дата выпуска: 16.07.2026
SQL Server 2022 — Версия: 16.0.4265.3
Analysis Services — Версия: 16.0.43.252
Краткое описание изменений
Описание: KB5096981
Скачать: SQLServer2025-KB5096981-x64.exe
Дата выпуска: 16.07.2026
SQL Server 2025 — Версия: 17.0.4065.4
Analysis Services — Версия: 17.0.25.223
Автор: 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).
После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.
Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions
За последние пару месяцев я выполнил много работы по настройке производительности, и в эти выходные обнаружил нечто, очень распространённое в реальных системах. Кимберли помогала мне оптимизировать один сложный план запроса и заметила в коде то, чего я не увидел, — это приводило к просмотру индекса вместо поиска по индексу. Несмотря на то, что план запроса использовал покрывающий некластерный индекс, способ написания кода заставлял индекс сканироваться.
Я подготовлю тестовый пример, чтобы показать, что я имею в виду.
Автор: Paul Randal, Tracking expensive queries with extended events in SQL 2008
В рамках курса для администраторов баз данных, который мы проводим здесь, в Мельбурне, я выполнил демонстрацию использования предикатов и файловых целей с расширенными событиями, поэтому я хочу выложить скрипт, чтобы люди могли с ним поиграть.
Автор: Paul Randal, Important considerations when performance tuning
Что, по вашему мнению, является самым важным аспектом при настройке производительности, если бы пришлось выбрать что-то одно? Суть в том, что в общем случае ответ всегда «зависит», но некоторые вещи оказываются главной проблемой чаще, чем другие. Давайте пройдёмся по каждому возможному ответу и посмотрим, как сильно они могут повлиять на производительность, если что-то не так. Это ни в коем случае не исчерпывающий список того, что может вызвать проблемы, а просто мои размышления в конце воскресенья, как обычно.
Автор: Штеффен Краузе (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, которая предоставляет простой способ отслеживания изменений данных в наборе таблиц базы данных для последующей передачи этих изменений во вторую систему, например, в хранилище данных. В этом документе содержатся рекомендации по настройке параметров отслеживания изменений данных для максимальной производительности захвата данных при минимальном влиянии на производительность производственной нагрузки. Область действия этого документа ограничена захватом изменяемых данных и процессом очистки. Запрос изменённых данных не входит в область действия данного технического документа.
Автор: Chad Callihan , SQL Formatting in SSMS 22.7
Форматирование кода может быть деликатной темой. Иногда существуют чёткие правила, определяющие правильное и неправильное, а иногда их нет. Пробелы против табуляции, что выбрать?
Как ни удивительно, но в SQL Server Management Studio никогда не было встроенного средства форматирования SQL. Пользователям всегда приходилось пользоваться сторонними инструментами или форматировать вручную. Но с выходом последней версии SSMS 22.7 форматирование SQL наконец стало встроенной функцией.
Давайте рассмотрим несколько примеров и посмотрим, как она работает.
Автор: 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'?»
Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)
Описание: KB5093421
Скачать: SQLServer2025-KB5093421-x64.exe
Дата выпуска: 17 июня 2026 г.
SQL Server 2025 — Версия: 17.0.4055.5
Обычно, когда я рассказываю людям об оптимистичных уровнях изоляции SQL Server — Read Committed Snapshot Isolation (RCSI) и Snapshot Isolation (SI) — мне приходится произносить небольшую речь о том, что им нужно тестировать свои запросы, потому что результаты могут измениться.
Однако недавно я работал с клиентом, который получал неверные результаты запросов при использовании пессимистичного уровня изоляции по умолчанию — и мы переключились на RCSI, чтобы это исправить! Я не буду объяснять здесь RCSI или SI — используйте ссылку выше для ознакомления с основами — вместо этого я сосредоточусь на демонстрационном скрипте, который я написал, чтобы показать проблему, с которой они столкнулись, и то, как RCSI её решил.
Автор: 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.com от Ричи Рамп (Richie Rump). Теперь пользоваться им стало ещё проще.
Скачайте и установите расширение, затем выполните ваш запрос с включёнными SET STATISTICS IO, TIME ON, и после завершения щёлкните правой кнопкой мыши в окне запроса и выберите Parse Statistics.
Вы когда-нибудь задумывались, почему ваш ЦП достигает 100% при низком объёме запросов? В этой статье я разберу механизм «Штормов компиляции» (Compilation Storms) и покажу, как обнаружить узкие места типа SOS_CACHESTORE менее чем за минуту.
SOS_CACHESTORE означает интенсивную конкуренцию за кэш планов.Управление высококонкурентной средой SQL Server — это игра на миллиметры. Мы часто говорим о «быстрых запросах», но редко говорим о налоге, который движок платит до того, как запрос вообще начнётся: о компиляции. Когда ваш кэш планов нестабилен, SQL Server входит в «Шторм компиляции», превращая ваши высококлассные ЦП в дорогие обогреватели. Давайте заглянем под капот.
Краткий обзор. Собственные функции регулярных выражений (regex) в T-SQL теперь принимают входные данные типа varchar(max) и nvarchar(max) размером до 2 МБ во всех семи функциях регулярных выражений, включая две табличные функции (REGEXP_MATCHES и REGEXP_SPLIT_TO_TABLE). Эта возможность поставляется в SQL Server 2025 CU5. Вам больше не нужно разбивать файлы журналов, HTML-документы или большие JSON-нагрузки на 8000-байтовые фрагменты только для того, чтобы выполнить сопоставление с шаблоном.
Вы исправили ad-hoc запросы, но ваш сервер всё ещё «колбасит»? В этой статье я расскажу, почему даже идеальная параметризация может привести к «токсичности повторного использования» (reuse toxicity) и массовым скачкам ЦП.
min_worker_time и max_worker_time указывают на войну, вызванную Sniffing'ом параметров.query_hash и оптимизацию PSP в SQL Server 2022.В предыдущей части этой серии мы очистили кэш от «мусорных» планов. Но горькая правда в том, что чистый код не гарантирует чистый кэш. Даже когда ваше приложение на 100% параметризовано, SQL Server всё ещё может страдать от другого вида засорения — логической токсичности. Это происходит, когда движок повторно использует неоптимальный план выполнения, потому что во время компиляции он «унюхал» (sniffed) непредставительный параметр.