В первой части статьи «Малоиспользуемые индексы в группах доступности – Часть 1» я показал, как с помощью динамического SQL собрать статистику использования индексов для заданной таблицы со всех реплик в группе доступности. Знать использование по всем нагрузкам, безусловно, лучше, чем смотреть только на первичную или на одну вторичную. Но что если я хочу принимать ещё более взвешенные решения, добавив к выводу количество строк, размер и столбцы индексов?
Системы с высокой параллельностью на бумаге всегда выглядят впечатляюще. Вы добавляете десятки процессорных ядер, увеличиваете объём памяти, проектируете схему с «лёгкими» вставками и с удовлетворением думаете: «Всё полетит». И, по правде говоря, при небольшой нагрузке так и выходит. Одна сессия, вставляющая строки в простую таблицу, даже не заставляет SQL Server напрячься.
Но картина меняется, как только вы начинаете нагружать систему сотнями параллельных вставок. Внезапно вся вычислительная мощь перестаёт иметь значение, потому что каждый поток бьётся за одно крошечное место в памяти: последнюю страницу кластерного индекса. Это классическая проблема «last-page insert contention problem». Она возникает всякий раз, когда ключ кластерного индекса последовательный — типичные IDENTITY, DATETIME или NEWSEQUENTIALID(). Каждая новая строка естественным образом «тянется» в конец B-дерева. Это звучит упорядоченно и эффективно, но при конкуренции — это ловушка. Вместо распределения вставок по нескольким страницам все они наваливаются на одну «горячую» страницу.
В SQL Server 2025 компания Microsoft представила новое динамическое административное представление (DMV) sys.dm_os_memory_health_history. Ключевые моменты:
Я читал пост Брента Озара о регулярных выражениях в 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.
Columnstore-индексы прошли длинный путь с момента появления в SQL Server 2012. В каждом новом выпуске они становились быстрее, гибче и удобнее в обслуживании. В SQL Server 2025 Microsoft добавила очередную порцию улучшений — теперь упор сделан на производительность и непрерывность работы.
shrink при наличии столбцов с MAX-типамиУскоренное восстановление базы данных (Accelerated Database Recovery, ADR) появилось в SQL Server 2019. Его основная цель — обеспечить более быстрое восстановление базы данных в случае сбоя или неожиданного выключения. Традиционно процесс восстановления включал несколько фаз — анализ, повторное выполнение (redo) и откат (undo). Этот подход мог быть неэффективным и долгим, особенно при наличии длительных транзакций.
Если коротко, ADR упрощает процесс восстановления благодаря новому подходу к откату. Вместо того чтобы полностью полагаться на сканирование журнала транзакций — что может быть крайне медленно при откате незавершённых или долгих транзакций — ADR ведёт специальное хранилище версий внутри пользовательской базы данных, где фиксируются изменения на уровне строк. Это позволяет SQL Server быстро откатывать незавершённые транзакции без сканирования всего журнала. Результат — значительно более быстрое восстановление после сбоя, мгновенный откат и общая улучшенная доступность базы данных, особенно в высоконагруженных средах.
Columnstore-индексы – это мощный инструмент для хранения аналитических данных прямо в SQL Server. Эта функция улучшалась в каждой версии SQL Server за последние десять лет, и SQL Server 2025 не стал исключением.
Новые улучшения сосредоточены на обеспечении непрерывности бизнеса и повышении производительности. Упорядоченные (ordered) кластерные и некластерные columnstore-индексы, а также операции сжатия базы данных и файлов получили значительные улучшения.
Обратная связь по степени параллелизма (DOP feedback) теперь включена по умолчанию в SQL Server 2025 (Preview), Azure SQL Database, SQL Database в Microsoft Fabric и в политике Always-up-to-date для Azure SQL Managed Instance.
Автор: Dimitri Furman, MICROSOFT, 19 мая 2025г. SQL Server 2025: introducing optimized Halloween protection
Оптимизированная в SQL Server 2025 (начиная с CTP 2.0) защита «Halloween Protection», сокращает потребление места в tempdb и повышает производительность запросов, снижает потребление ресурсов, а также решает саму проблему Хэллоуина. При этом не требуется вносить какие-либо изменения в запросы пользователей. Тестирование ряда выбранных для примера приложений показали что утилизация процессоров и время исполнения таких запросов сократились примерно наполовину, а также полностью исчезло использование места в базе данных tempdb.
Автор: 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
В SQL Server 2025 добавлена новая функция резервного копирования, позволяющая использовать для сжатия алгоритм Zstandard (ZSTD), который, как было анонсировано, будет работать лучшие, чем стандартный MS_XPRESS, и при этом его будет проще настраивать, чем Intel QAT. Алгоритм сжатия ZSTD доступен начиная с предварительной версии SQL Server 2025 (17.x).
Описание: KB5054531
Скачать: SQLServer2022-KB5054531-x64.exe
Дата выпуска: 15 мая 2025 г.
Автор: Craig Freedman Implicit Conversions
В нескольких статьях я уже показывал, как явные преобразования могут приводить к ошибкам. В этой статье рассмотрим некоторые проблемы, связанные с неявными преобразованиями. SQL Server добавляет неявные преобразования, когда в одном выражении запроса используются колонки, переменные и/или параметры с разными (но совместимыми) типами данных. Например, если нужно сравнить колонки с типами INT и FLOAT, INT необходимо преобразовать в FLOAT. Если вы напишете "C_INT = C_FLOAT", SQL Server перепишет это выражение как "CONVERT (FLOAT, C_INT) = C_FLOAT".
Автор: 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.
Автор: Craig Freedman OPTIMIZED Nested Loops Joins
В предыдущих двух статьях мы рассмотрели при каких условиях SQL Server может добавить сортировку на внешней стороне соединения вложенных циклов и как эта сортировка может повысить производительность. А чуть раннее мы увидели как SQL Server может использовать упреждающую случайную выборку для повышения производительности соединения вложенных циклов. В этой статье давайте исследуем еще одну возможность повышения производительности соединения вложенных циклов. Я буду использовать ту же базу данных, которую использовал в двух предыдущих статьях.
Автор: Craig Freedman Optimizing I/O Performance by Sorting – Part 2
В предыдущей части мы рассмотрели, как SQL Server использует сортировку для преобразования случайных операций ввода-вывода в последовательные. В этой части давайте наглядно продемонстрируем, как такая сортировка может повлиять на производительность. Для проверки я буду использовать ту же базу данных размером 3 ГБ, которая была создана в первой части.
Автор: 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, обычно приходящими от отчётных и аналитических приложений. Мы тут не будем в это углубляться, поскольку это не является темой данной статьи.
Автор: Craig Freedman Bookmark Lookup
Перевод Ирины Наумовой
В своей прошлой статье, я рассказал о том, как SQL Server использует индекс для эффективного обращения к строке, квалифицируемой предикатом. Для принятия решения о том использовать ли индекс, SQL Server рассматривает несколько факторов, которые включают проверку того, покрывает ли индекс все используемые в запросе столбцы задействованной таблицы.
Автор: Craig Freedman Sequential Read Ahead
Балансировка загрузки процессоров и ввода-вывода очень важна для обеспечения лучшей производительности и оптимизации обслуживания нагрузки сервера. В SQL Server реализованы два механизма асинхронного ввода-вывода: последовательное упреждающее чтение (sequential read ahead) и случайная упреждающая выборка (random prefetching). Оба они предназначены для балансировки нагрузки в многопроцессорных системах.
Автор: Craig Freedman Scans vs. Seeks
Scan и Seek — это итераторы, которые SQL Server использует для чтения данных из таблиц и индексов. Эти итераторы являются одними из самых фундаментальных, которые можно встретить почти в каждом в плане запроса. Так в чем разница между Scan (просмотром) и Seek (поиском)?