Я читал пост Брента Озара о регулярных выражениях в 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
.
8.9.25
Новое в SQL Server 2025: Кардинальность и REGEXP_LIKE
4.9.25
Что нового для columnstore-индексов в SQL Server 2025
Columnstore-индексы прошли длинный путь с момента появления в SQL Server 2012. В каждом новом выпуске они становились быстрее, гибче и удобнее в обслуживании. В SQL Server 2025 Microsoft добавила очередную порцию улучшений — теперь упор сделан на производительность и непрерывность работы.
Три ключевых изменения
- Упорядоченные некластеризованные columnstore-индексы
- Онлайн-перестроение упорядоченных columnstore-индексов
- Более эффективный
shrink
при наличии столбцов с MAX-типами
26.8.25
Ускоренное восстановление базы данных в SQL Server 2025
Ускоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019. Его основная цель — обеспечить более быстрое восстановление базы данных в случае сбоя или неожиданного выключения. Традиционно процесс восстановления включал несколько фаз — анализ, повторное выполнение (redo) и откат (undo). Этот подход мог быть неэффективным и долгим, особенно при наличии длительных транзакций.
Если коротко, ADR упрощает процесс восстановления благодаря новому подходу к откату. Вместо того чтобы полностью полагаться на сканирование журнала транзакций — что может быть крайне медленно при откате незавершённых или долгих транзакций — ADR ведёт специальное хранилище версий внутри пользовательской базы данных, где фиксируются изменения на уровне строк. Это позволяет SQL Server быстро откатывать незавершённые транзакции без сканирования всего журнала. Результат — значительно более быстрое восстановление после сбоя, мгновенный откат и общая улучшенная доступность базы данных, особенно в высоконагруженных средах.
25.8.25
Улучшения Columnstore-индексов в SQL Server 2025
Columnstore-индексы – это мощный инструмент для хранения аналитических данных прямо в SQL Server. Эта функция улучшалась в каждой версии SQL Server за последние десять лет, и SQL Server 2025 не стал исключением.
Новые улучшения сосредоточены на обеспечении непрерывности бизнеса и повышении производительности. Упорядоченные (ordered) кластерные и некластерные columnstore-индексы, а также операции сжатия базы данных и файлов получили значительные улучшения.
24.8.25
Умный параллелизм: обратная связь по степени параллелизма (DOP) в SQL Server 2025
Обратная связь по степени параллелизма (DOP feedback) теперь включена по умолчанию в SQL Server 2025 (Preview), Azure SQL Database, SQL Database в Microsoft Fabric и в политике Always-up-to-date для Azure SQL Managed Instance.
30.6.25
Новое в SQL Server 2025: Оптимизация Halloween Protection

Автор: Dimitri Furman, MICROSOFT, 19 мая 2025г. SQL Server 2025: introducing optimized Halloween protection
Оптимизированная в SQL Server 2025 (начиная с CTP 2.0) защита «Halloween Protection», сокращает потребление места в tempdb и повышает производительность запросов, снижает потребление ресурсов, а также решает саму проблему Хэллоуина. При этом не требуется вносить какие-либо изменения в запросы пользователей. Тестирование ряда выбранных для примера приложений показали что утилизация процессоров и время исполнения таких запросов сократились примерно наполовину, а также полностью исчезло использование места в базе данных tempdb.
23.6.25
Новое в SQL Server 2025: ограничение использования tempdb добавлено в Resource Governor

Автор: Dimitri Furman, MICROSOFT, 19 мая 2025г. SQL Server 2025: introducing tempdb space resource governance
С начала существования SQL
Server администраторам баз данных приходилось сталкиваться с распространённой
проблемой — нехваткой места в базе данных tempdb.
Мне всегда казалось странным, что всё, что мне нужно для сбоя в работе экземпляра SQL Server, — это доступ к серверу, на котором я могу создать временную таблицу, заполняющую всю tempdb, и никто не сможет меня остановить.
- Erland Sommarskog, независимый консультант по SQL Server и Data Platform MVP
Поскольку tempdb используется
сервером для большого числа разных задач, проблема может возникнуть не только
из-за действий пользователей, таких как создание временной таблицы. Например,
выполнение запроса для отчета, который материализует данные в tempdb, может
привести к сбою всех активных на этом экземпляре SQL Server процессов.
На протяжении многих лет
администраторы баз данных разрабатывали собственные решения, которые
отслеживали использование места в tempdb и предпринимали соответствующие
ситуации действия, например, завершали сеансы, которые сильно утилизировали
место в этой системной базе. Но это всегда требовало дополнительных
знаний, опыта, усилий и было сложным делом.
За свою карьеру я потратил больше времени, чем поддаётся подсчёту, на создание решений для управления местом в tempdb. Даже несмотря на то, что я потратил много времени и сил, всё равно возникали проблемы и сложности, особенно в многопользовательских приложениях с большим количеством баз данных и с проблемой «шумных соседей».
- Edward Pollack, работает в Transfinder архитектором данных и является Data Platform MVP
17.6.25
Новое в SQL Server 2025: Сжатие резервных копий алгоритмом Zstandard

В SQL Server 2025 добавлена новая функция резервного копирования, позволяющая использовать для сжатия алгоритм Zstandard (ZSTD), который, как было анонсировано, будет работать лучшие, чем стандартный MS_XPRESS, и при этом его будет проще настраивать, чем Intel QAT. Алгоритм сжатия ZSTD доступен начиная с предварительной версии SQL Server 2025 (17.x).
16.5.25
Накопительный пакет обновления 19 для SQL Server 2022 - KB5054531
Описание: KB5054531
Скачать: SQLServer2022-KB5054531-x64.exe
Дата выпуска: 15 мая 2025 г.
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".
18.2.25
Подразумеваемые (Implied) предикаты

Автор: Craig Freedman Implied Predicates and Query Hints
В этой статье будут рассмотрены некоторые странности с
предикатами в планах запросов. Рассмотрим следующую тривиальную схему и запрос:
CREATE TABLE T1 (A INT, B INT)
CREATE TABLE T2 (A INT, B INT)
SELECT *
FROM T1 INNER JOIN T2 ON T1.A = T2.A
WHERE T1.B = 0
OPTION (HASH JOIN)
Как и задумывалось, этот запрос будет выполняться со следующим планом:
|--Hash Match(Inner Join,
HASH:([T1].[A])=([T2].[A]), RESIDUAL:([T2].[A]=[T1].[A]))
|--Table
Scan(OBJECT:([T1]), WHERE:([T1].[B]=(0)))
|--Table Scan(OBJECT:([T2]))
На самом деле, этот запрос получит такой план с подсказкой или без нее. Теперь давайте внесем небольшое изменение в предложение WHERE и посмотрим, что произойдет:
SELECT *
FROM T1 INNER JOIN T2 ON T1.A = T2.A
WHERE T1.A = 0
OPTION (HASH JOIN)
Теперь этот запрос выдает сообщение об ошибке:
Msg 8622, Level 16, State 1, Line 1
Query processor could not produce a query plan because of the hints defined in this query. Resubmit the query without specifying any hints and without using SET FORCEPLAN.
6.2.25
OPTIMIZED Nested Loops Joins

Автор: Craig Freedman OPTIMIZED Nested Loops Joins
В предыдущих двух статьях мы рассмотрели при каких условиях SQL Server может добавить сортировку на внешней стороне соединения вложенных циклов и как эта сортировка может повысить производительность. А чуть раннее мы увидели как SQL Server может использовать упреждающую случайную выборку для повышения производительности соединения вложенных циклов. В этой статье давайте исследуем еще одну возможность повышения производительности соединения вложенных циклов. Я буду использовать ту же базу данных, которую использовал в двух предыдущих статьях.
3.2.25
Optimizing I/O Performance by Sorting – Part 2

Автор: Craig Freedman Optimizing I/O Performance by Sorting – Part 2
В предыдущей части мы рассмотрели, как SQL Server использует сортировку для преобразования случайных операций ввода-вывода в последовательные. В этой части давайте наглядно продемонстрируем, как такая сортировка может повлиять на производительность. Для проверки я буду использовать ту же базу данных размером 3 ГБ, которая была создана в первой части.
27.1.25
Новое в SQL Server 2022: Improved RCSI Ghost Cleanup

Автор: Paul White https://www.sql.kiwi/2024/12/improved-ghosts-2022/
Уровень изоляции моментального снимка с фиксированным чтением (Read Committed Snapshot Isolation, далее: RCSI) даёт много преимуществ. Главное из них в том, что читатели не будут блокировать писателей (и наоборот). Каждый оператор видит снимок данных на определенный момент времени (за исключением некоторых случаев, таких как использование non-inlined функций, которые оптимизатор не может развернуть внутри запроса). С другой стороны, появляются затраты на поддержание версий строк, необходимых для реализации RCSI.
Речь идет не только о том, чтобы
убедиться, что база данных tempdb (или пользовательская
база данных (если используется ADR - ACCELERATED_DATABASE_RECOVERY) достаточно велика и может
справиться с дополнительной параллельной активностью:
- Писатели,
изменяющие (а иногда и добавляющие) данные, должны создавать версии строк.
- Система
должна уметь проверять и поддерживать компактность хранилища версий в фоновом
режиме.
- Читателям
необходимо найти правильную для них версию каждой строки выборки.
Последний пункт может привести к значительному снижению производительности, если в результате пользовательской активности получились длинные цепочки версий. RCSI подвержен подобным проблемам меньше, чем SI, поскольку каждый оператор RCSI видит более позднюю точку во времени. Но это не исключает проблем с долгими запросами с RCSI, обычно приходящими от отчётных и аналитических приложений. Мы тут не будем в это углубляться, поскольку это не является темой данной статьи.
26.11.24
Bookmark Lookup

Автор: Craig Freedman Bookmark Lookup
Перевод Ирины Наумовой
В своей прошлой статье, я рассказал о том, как SQL Server использует индекс для эффективного обращения к строке, квалифицируемой предикатом. Для принятия решения о том использовать ли индекс, SQL Server рассматривает несколько факторов, которые включают проверку того, покрывает ли индекс все используемые в запросе столбцы задействованной таблицы.
25.11.24
Sequential Read Ahead

Автор: Craig Freedman Sequential Read Ahead
Балансировка загрузки процессоров и ввода-вывода очень важна для обеспечения лучшей производительности и оптимизации обслуживания нагрузки сервера. В SQL Server реализованы два механизма асинхронного ввода-вывода: последовательное упреждающее чтение (sequential read ahead) и случайная упреждающая выборка (random prefetching). Оба они предназначены для балансировки нагрузки в многопроцессорных системах.
15.11.24
Scans vs Seeks

Автор: Craig Freedman Scans vs. Seeks
Scan и Seek — это итераторы, которые SQL Server использует для чтения данных из таблиц и индексов. Эти итераторы являются одними из самых фундаментальных, которые можно встретить почти в каждом в плане запроса. Так в чем разница между Scan (просмотром) и Seek (поиском)?
1.11.24
Накопительный пакет обновления 29 для SQL Server 2019 - KB5046365

SQL Server 2019 — версия: 15.0.4405.4
Описание: KB5046365
Скачать: SQLServer2019-KB5046365-x64.exe
14.10.24
CASE Subqueries in BETWEEN and CASE Statements
Автор:
Craig Freedman Subqueries in BETWEEN and CASE
Statements
Рассмотрим следующий запрос:
CREATE TABLE T1 (A INT, B1 INT, B2 INT)
CREATE TABLE T2 (A INT, B INT)
SELECT *
FROM T1
WHERE (SELECT SUM(T2.B) FROM T2 WHERE T2.A = T1.A) BETWEEN T1.B1 AND T1.B2
26.9.24
Новое в SQL Server 2022: улучшения в sys.dm_exec_query_statistics_xml

Автор: Vivek Janakiraman Unleashing SQL Server 2022: Enhancements to sys.dm_exec_query_statistics_xml
Одним из улучшений в SQL Server 2022 является дальнейшее совершенствование динамического административного представления (DMV) sys.dm_exec_query_statistics_xml. Этот DMV предоставляет подробную статистику выполнения запросов, что очень полезно для повышения их производительности и для оптимизации.