3.10.25
Малоиспользуемые индексы в группах доступности – Часть 1
В рамках оптимизации производительности я оцениваю использование индексов на множестве экземпляров и в разных базах данных. Часто обнаруживается, что некоторые индексы используются нечасто или, по крайней мере на первый взгляд, кажутся неиспользуемыми. Поскольку мы используем группы доступности (AG), разные рабочие нагрузки выполняются на репликах в разных ролях. Все операции записи, разумеется, происходят на первичной. Однако некоторые запросы выполняются только на вторичных репликах для чтения (либо за счёт маршрутизации чтения, либо потому, что отдельные процессы вручную направляются на конкретные вторичные, либо же и то и другое). К сожалению, статистика использования индексов нигде не агрегируется по всем репликам сразу. Это значит, что анализ только первичной реплики даёт неполную картину. Как убедиться, что я учитываю активность индексов везде, а не только на первичной?
1.10.25
Включаем умный параллелелизм вставки с помощью OPTIMIZE_FOR_SEQUENTIAL_KEY
Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.
Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.
21.9.25
Доступ к Kubernetes API из SQL Server 2025
Хранимая процедура sp_invoke_external_rest_endpoint
, появившаяся в версии SQL Server 2025, позволяет обращаться к внешним конечным точкам REST API прямо из SQL Server. Это открывает множество интересных возможностей. Недавно я задумался: ведь Kubernetes тоже предоставляет REST API. Можно ли обратиться к нему напрямую из SQL Server?
Давайте посмотрим, как это сделать. Пошагово план такой:
- Создать локальный центр сертификации (CA), приватный RSA-ключ и подписанный сертификат
- Развернуть обратный прокси в Kubernetes
- Настроить SQL Server для обращения к прокси
- Использовать хранимую процедуру для вызова Kubernetes API через прокси
19.9.25
Новое в SQL Server 2025: REGEXP_INSTR и REGEXP_COUNT
Не могу поверить, что наконец-то добрался до этого. Я почти решился разделить описание последних двух функций на две статьи, но решил, что они настолько похожи на остальные, что можно обойтись одной. Подобно тому, как Профессор и Мэри Энн были не менее важны, чем другие потерпевшие кораблекрушение, эти функции тоже очень полезны, а краткость изложения тут только потому, что по принципу работы они очень похожи на все остальные. Я определенно продемонстрирую функциональность каждой функции, но не так подробно, как в предыдущих статьях.
В этой статье мы рассмотрим:
- REGEXP_INSTR — Возвращает начальную или конечную позицию соответствующей подстроки в зависимости от значения аргумента return_option.
- REGEXP_COUNT — Подсчитывает количество совпадений шаблона регулярного выражения в строке.
17.9.25
Всё, что нужно знать про управление ключами TDE при восстановлении базы данных
Прозрачное шифрование данных (TDE) в Azure SQL с ключом, управляемым клиентом (Customer-Managed Key, CMK), поддерживает сценарий «принеси свой ключ» (Bring Your Own Key — BYOK) для защиты данных в состоянии покоя и даёт возможность разделения обязанностей по управлению ключами и данными. При клиентском управлении TDE пользователь отвечает за жизненный цикл ключей (создание, загрузка, ротация, удаление), права на их использование и аудит операций с ключами. Ключ, используемый для шифрования ключа шифрования базы данных (Database Encryption Key, DEK), называемый TDE-протектором, — это асимметричный ключ, которым управляет клиент и который хранится в Azure Key Vault.
После включения TDE с использованием ключа из Key Vault новые резервные копии продолжают шифроваться с использованием того же TDE-протектора. Смена TDE-протектора не изменяет уже созданные резервные копии — чтобы восстановить резервную копию, зашифрованную ключом Key Vault, необходимо, чтобы материал соответствующего ключа был доступен серверу, на который выполняется восстановление. Особенность реализации TDE требует, чтобы для успешного восстановления были доступны как текущий, так и предыдущие TDE-протекторы. Рекомендуется сохранять все предыдущие версии протектора в хранилище ключей, чтобы иметь возможность восстановить резервные копии базы данных.
В этой статье подробно объясняются, какие ключи должны быть доступны для восстановления базы данных и почему это необходимо.
16.9.25
Новое в SQL Server 2025: REST API и переосмысливание резервного копирования снимков
В этой статье я покажу, как с помощью T-SQL-скрипта создавать согласованные с приложениями моментальные снимки
на Pure Storage FlashArray прямо из SQL Server, без использования внешних инструментов.
В SQL Server 2025 появилась мощная новая возможность: хранимая процедура
sp_invoke_external_rest_endpoint
. Она значительно облегчает вызов REST API напрямую из T-SQL.
В сочетании с API Pure Storage эта функция позволяет полностью автоматизировать процесс создания снимков без внешних скриптов и инструментов.
Если вы следили за моей серией публикаций Using T-SQL Snapshot Backup, вы знаете, что данная технология особенно полезна в крупных базах данных. Сегодня мы рассмотрим, как реализовать её непосредственно в T-SQL, используя возможность SQL Server обращаться к REST API. PowerShell не потребуется.
14.9.25
Новое в SQL Server 2025: Функция REGEXP_REPLACE
Мы уже рассмотрели столько способов фильтрации с помощью регулярных выражений, сколько, на мой взгляд, реализовано в SQL Server 2025. Теперь пришло время сосредоточиться на функциях, которые не являются REGEXP_LIKE
. Мы уже говорили о REGEXP_MATCHES
, которая пригодится в дальнейшем.
Я начну с REGEXP_REPLACE
, которая похожа на обычную функцию SQL REPLACE
. Но вместо замены на основе статического разделителя, она может заменять несколько (или конкретное) значение, совпадающее с регулярным выражением. Все мои примеры в этой статье будут использовать просто переменную со значением, над которым мы работаем, так что создавать или загружать объекты не нужно.
13.9.25
Новое в SQL Server 2025: Функция REGEXP_SPLIT_TO_TABLE
Продолжим рассмотрение функций семейства REGEXP_, следующая, на которой я хочу остановиться, — это табличная функция REGEXP_SPLIT_TO_TABLE
. Это определённо одна из тех функций, которые стоит знать, особенно если когда-либо потребуется извлекать данные из сложной структуры.
Эта функция очень похожа на STRING_SPLIT
. И, в отличие от таких функций, как REGEXP_LIKE
, в простых случаях здесь можно использовать те же основные параметры, что и у STRING_SPLIT
. Но далее возможности становятся практически безграничными, потому что можно определить почти любые разделители. Конечно, у функции есть и недостатки, но об этом поговорим позже.
12.9.25
Новое в SQL Server 2025: Поиск совпадений с помощью функций регулярных выражений
Цель этой статьи — показать, как можно находить несколько совпадений с использованием регулярных выражений SQL Server, чтобы примеры были более наглядными (особенно в последующих частях).
Существует несколько функций, которые позволяют в выводе результата показать несколько совпадений фрагмента строки или шаблона:
- REGEXP_REPLACE – возвращает измененную исходную строку, замененную строкой замены, в которой найдено вхождение шаблона регулярного выражения. Если совпадения не найдены, функция возвращает исходную строку.
- REGEXP_SUBSTR – возвращает одно вхождение подстроки в анализируемой строке, которое соответствует шаблону регулярного выражения. Если совпадение не найдено, возвращается NULL.
- REGEXP_INSTR – возвращает начальную или конечную позицию соответствующей подстроки в зависимости от значения аргумента return_option.
- REGEXP_COUNT – подсчитывает количество совпадений шаблона регулярного выражения в строке.
- REGEXP_SPLIT_TO_TABLE – используется аналогично функции SPLIT_TO_TABLE, но возвращает таблицу строк, разделенную шаблоном регулярных выражений. Если шаблон не соответствует, функция возвращает строку.
- REGEXP_MATCHES – возвращает таблицу захваченных подстрок, которые соответствуют шаблону регулярного выражения строке. Если совпадение не найдено, функция не возвращает строку.
11.9.25
Новое в SQL Server 2025: Функция REGEXP_SUBSTR
Функция REGEXP_SUBSTR
извлекает части строки на основе шаблона регулярного выражения. Она имеет сходство с функцией SUBSTRING
, но есть и важные (и интересные) различия. Эта функция возвращает N-ое вхождение подстроки, которая соответствует регулярному выражению.
Когда я начал писать десятую статью в серии о регулярных выражениях в SQL Server, я должен признаться: я не знал заранее, что именно эта функция делает. Классическая функция SUBSTRING
принимает строго позиционные параметры. Задана строка, указываешь начальную позицию и количество символов — и получаешь результат. Никакого сопоставления с шаблоном. К счастью для вас, изучение этого материала у меня заняло совсем немного времени.
В одной из предыдущих статей, где речь шла о REGEXP_MATCHES
, я показывал, как можно увидеть все совпадения, которые регулярное выражение находит в строке. REGEXP_SUBSTR
в своей простой форме возвращает скалярный результат — то есть одно совпадение.
Страсти по SQL Server 2025: ускоренное восстановление базы данных не исправляет проблему NOLOCK!!!
Я никогда не видел в T-SQL такой фразы, которую так же любят использовать, как NOLOCK. Мне постоянно кажется, что я написал уже достаточно публикаций об этом, но вот недавно клиент высказал новую идею:
Мы используем Accelerated Database Recovery в SQL Server 2022, который хранит версии строк внутри таблицы. К тому же мы не используем транзакции — наши операции вставки, обновления и удаления выполняются над одной таблицей за раз, а ваши демонстрации всегда используют транзакции, поэтому нас это не затрагивает.
10.9.25
Новое в SQL Server 2025: Функция REGEXP_COUNT
Бывает необходимо подсчитать, сколько раз определенная строка встречается в тексте. Однако формат этой строки может меняться. Например, существует несколько способов записи одного и того же номера телефона, и все они являются допустимыми форматами. Возможно ли это сделать в T-SQL? Давайте рассмотрим, как может помочь функция REGEXP_COUNT.
9.9.25
2025 год: инструменты для администрирования MSSQL
Если вы занимаетесь сейчас администрированием SQL Server, то, скорее всего, работаете с локальными экземплярами, облачными базами данных и, возможно, несколькими контейнерами. Набор инструментов, который вы выбираете, имеет значение для производительности, надежности и повседневного удобства работы. Ниже приведён обзор того, что использовать (и когда), с плюсами и минусами, подводными камнями и достоверными ссылками.
Новое в SQL Server 2025: функция PRODUCT()
С каждой версией SQL Server появляются новые возможности, за которые мы благодарны — наконец-то появляется доступ к полезным функциям, которые уже были в других системах.
В SQL Server 2025 CTP 1.3 была представлена функция PRODUCT(). Она ведёт себя похоже на SUM()
, но умножает значения вместо того, чтобы их складывать. Это агрегатная функция в SQL Server, следовательно, она действует на набор данных, а не на скалярные значения.
8.9.25
Новое в SQL Server 2025: Кардинальность и 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
.
7.9.25
T-SQL получил Regex в SQL Server 2025. Но не спешите радоваться
Регулярные выражения позволяют выполнять сложные поиски по строкам. Они действительно полезны, но у них репутация: их трудно писать, трудно читать и ещё сложнее отлаживать. Однако, освоив их, можно решать очень специфические задачи.
Этот пост не про сложность, а про производительность regex в Azure SQL DB и SQL Server 2025.
Regex как Everclear
Everclear — это марка алкоголя. Звучит заманчиво: без запаха, вкуса и цвета. Но на самом деле это 95% чистого спирта, настолько крепкий, что во многих штатах США его просто запретили. Даже в Неваде, где разрешены казино, оружие и марихуана.
3.9.25
Функция REGEXP_LIKE в SQL Server 2025
Мне нужно выполнить проверку данных в базе SQL Server. Однако правила слишком сложные для функции T-SQL LIKE
, и не удаётся реализовать их через PATINDEX
или что-то подобное.
Я хотел бы использовать регулярные выражения, так как они мощнее.
В SQL Server 2025 для этого теперь есть функция REGEXP_LIKE.
16.5.25
Подробнее о неявных преобразованиях

Автор: Craig Freedman More on Implicit Conversions
Меня попросили прокомментировать алгоритм, который SQL Server использует для выбора неявных преобразований. Когда SQL Server сталкивается в выражении с несовпадающими типами, он может выполнить запрос с неявным преобразованием или может завершить запрос ошибкой. Прежде чем углубляться в сценарий неявного преобразования, давайте кратко рассмотрим случай с ошибкой. Если неявное преобразование невозможно, возможны два варианта ошибки. Если оба типа данных несовместимы (то есть, если между двумя типами не допускается преобразование, неявное или явное), SQL Server сгенерирует следующую ошибку:
DECLARE @b DATE
SET @a = @b
Msg 206, Level 16, State 2, Line 3
Operand type clash: date is incompatible with int
25.4.25
Неявные преобразования (Implicit Conversions)

Автор: Craig Freedman Implicit Conversions
В нескольких статьях я уже показывал, как явные преобразования могут приводить к ошибкам. В этой статье рассмотрим некоторые проблемы, связанные с неявными преобразованиями. SQL Server добавляет неявные преобразования, когда в одном выражении запроса используются колонки, переменные и/или параметры с разными (но совместимыми) типами данных. Например, если нужно сравнить колонки с типами INT и FLOAT, INT необходимо преобразовать в FLOAT. Если вы напишете "C_INT = C_FLOAT", SQL Server перепишет это выражение как "CONVERT (FLOAT, C_INT) = C_FLOAT".
28.3.25
Maximum Row Size and Query Hints

Автор: Craig Freedman Maximum Row Size and Query Hints
В предыдущей статье
я привел пример того как подсказка оптимизатору в запросе может привести к ошибке
при его исполнении. В этой статье рассмотрим ещё один пример: как использование
хинтов может привести к проблемам. SQL Server имеет документированное
ограничение на максимальный размер строки в 8060 байт. Это ограничение
на размер строки применяется конкретно к фиксированной ширине или не
выходящей за пределы записи части колонок с типом переменной длинны. Если вы
попытаетесь создать таблицу, которая превышает это ограничение, вы столкнетесь
со следующей ошибкой:
CREATE TABLE T (A INT, B CHAR(8000), C CHAR(8000))
Msg 1701, Level 16,
State 1, Line 1
Creating or altering
table 'T' failed because the minimum row size would be 16011, including 7 bytes
of internal overhead. This exceeds the maximum allowable table row size of 8060
bytes.
Какое же отношение ограничение размера записи имеет к подсказкам оптимизатору?