Запрос, который вчера выполнялся за 200 миллисекунд, сегодня выполняется 14 секунд. Команда приложения заметила это раньше, чем инструмент мониторинга. К тому моменту, когда кто-то открывает сервер базы данных, в представлении активных запросов находится 47 сеансов, три из них заблокированы, и один из них удерживает блокировку, которая открыта уже шесть минут. Никто не может сказать вам, что делает этот сеанс, кому он принадлежит и безопасно ли его завершить. Это не проблема оборудования. Это проблема видимости. И она встречается чаще, чем следовало бы. Давайте поговорим о представлениях производительности в реальном времени, которые упрощают устранение неполадок.
16.4.26
Представления производительности в реальном времени, которые упрощают устранение неполадок
9.4.26
Углублённая диагностика и информативные панели мониторинга
Большинство инструментов мониторинга баз данных созданы не для той аудитории. Панели мониторинга предназначены для успокоения руководителей, оповещения откалиброваны для удовлетворения контрольных списков соответствия требованиям, а отчёты отформатированы для ежеквартальных обзоров. Ничто из этого не полезно в 10 часов вечера, когда приложение возвращает тайм-ауты, а дежурный разработчик просит обновлений каждые три минуты. То, что нужно администратору баз данных в этот момент, — это инструмент, который уже имеет контекст. Не сырые данные, которые нужно собирать в условиях стресса. Не список превышенных порогов. А реальный контекст: что выполнялось, что находилось в ожидании, что изменилось и как это сравнивается с тем, что является нормальным для данного конкретного экземпляра в это время суток. Это более сложная задача, чем кажется, и большинство инструментов мониторинга её не решают. Давайте поговорим об углублённой диагностике и информативных панелях мониторинга.
3.4.26
SQL Server Parameter Sniffing: ошибка, которая не является ошибкой (но всё ломает)
В этой статье вы узнаете, как выявить и победить нестабильную производительность в SQL Server. Если ваши запросы без предупреждения переходят от «молниеносных» к «еле ползущим», вы стали жертвой Parameter Sniffing. Пришло время вернуть контроль над вашими планами выполнения и остановить непредсказуемость.
Ваш запрос работает быстро, а затем внезапно… становится медленным!
У вас есть:
- Тот же запрос.
- Те же данные.
- Тот же сервер.
👉 Что изменилось?
💣 Parameter Sniffing. И нет… это НЕ ошибка. Это то, как SQL Server был спроектирован для работы.
30.3.26
Ваш план исполнения лжёт Вам...и Вы об этом не догадываетесь
уверен, что это случится с вами в какой-то момент... и с множеством ваших коллег также. Клиент сообщает вам, что ваше приложение работает крайне медленно. Вы уже идентифицировали проблемный запрос и…
Исполнение плана выглядит идеально…
но ваш запрос всё ещё медленно работает.
👉 Что-то лжёт вам.
И нет… не SQL Server! ....это то, как вы читаете план выполнения.
27.3.26
Перегружена ли индексами ваша база данных?
👉 Если вы пропустили мою предыдущую статью, ознакомьтесь с ней здесь: Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction
Ваш запрос работает медленно.
И вы добавляете индекс.
Запрос ускоряется… на мгновение.
Но затем всё остальное начинает работать медленнее.
👉 Что же произошло?
Возможно, вы перегружаете свою базу данных индексами.
26.3.26
Десять лучших практик настройки производительности SQL Server
Существует огромное количество лучших практик по настройке производительности SQL Server — я мог бы легко написать целую книгу на эту тему, особенно учитывая множество различных настроек базы данных, настроек сервера, практик написания кода, типов ожидания и так далее, которые могут влиять на производительность. Для этой статьи я решил немного отступить от списка конкретных деталей и дать несколько общих рекомендаций о том, как подходить к настройке производительности, чтобы максимизировать усилия и минимизировать отвлекающие факторы.
25.3.26
Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction
В предыдущей статье мы проанализировали улучшения производительности в SQL Server 2025 CU3 и обнаружили скрытые оптимизации, о которых никто не говорит.
👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит
В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).
22.3.26
Самая распространённая ошибка индексирования в SQL Server (и как её исправить)
Индексы — одна из самых мощных функций производительности в SQL Server. Но они также одни из самых непонятых. Многие разработчики считают, что добавление новых индексов автоматически улучшает производительность. К сожалению, часто бывает наоборот. Одна из самых распространённых проблем с производительностью SQL Server, которую я вижу в реальных системах, — это база данных, полная ненужных или плохо спроектированных индексов. Сегодня мы рассмотрим самую распространённую ошибку индексирования в SQL Server и способ её исправления.
17.3.26
Как удалось убрал 32 секунды из запроса без добавления индекса
Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.
Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.
Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.
Просто понимание того, как работает движок.
Приятного чтения — давайте заставим SQL Server летать.
Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)
16.3.26
Стратегии индексирования для производительности SQL Server
Один из самых простых способов повысить производительность запросов в SQL Server — обеспечить быстрый доступ к запрашиваемым данным, причём максимально эффективно. В SQL Server использование одного или нескольких индексов может стать именно тем решением, которое вам нужно. Фактически, индексы настолько важны, что SQL Server может даже предупредить вас, когда обнаружит, что отсутствует индекс, который был бы полезен для запроса. Это обзорная статья объяснит, что такое индексы, почему они так важны, а также немного об искусстве и науке разработки различных стратегий индексирования.
15.3.26
Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)
Назад к серии: Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)
Мы всё ещё говорим о пакетном режиме, потому что понимание того, когда он работает, так же важно, как и знание того, как его принудительно включить.
Сегодня мы углубимся: мы рассмотрим уровни совместимости, выделение памяти, оценку количества строк и флаги трассировки.
Приятного чтения, и пусть ваш CPU остаётся холодным при тяжёлых агрегатах!
13.3.26
Как указать Batch Mode для Rowstore, если его нет в плане (Часть 5)
Предыдущая статья: Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)
Давайте пристально изучим Actual Execution Plan, и углубимся в изучение пакетного режима для строчного хранения.
12.3.26
Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)
Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).
Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.
Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.
Если вы пропустили предыдущую часть, вы можете прочитать её здесь:
Но вот в чём поворот.
Начиная с SQL Server 2019, вам не всегда нужен колоночный индекс, чтобы получить производительность пакетного режима.
SQL Server может активировать пакетный режим для строчного хранения.
И иногда... как я сказал вам в начале этой статьи... ваш запрос становится в 5 или 10 раз быстрее без добавления ни одного индекса. Поэтому я предлагаю вам продолжить чтение...
11.3.26
Логические чтения не повторяемы на колоночных индексах (эх...)
Иногда я действительно ненавижу свою работу.
Вечно, ВЕЧНО, я мог утверждать: «Когда вы измеряете производительность хранилища во время настройки индексов и запросов, вы всегда должны использовать логические чтения, а не физические, потому что логические чтения повторяемы, а физические — нет. Физические чтения могут меняться в зависимости от того, что находится в кэше, какие другие запросы выполняются в данный момент, от редакции вашего SQL Server и от того, используются ли упреждающие чтения. Логические чтения просто отражают точное количество прочитанных страниц, независимо от того, откуда пришли данные (с диска или из кэша), так что пока это число уменьшается, вы делаете свою работу хорошо».
10.3.26
Фильтрованный индекс против индексированного представления и индекса с хранением в колонках (Часть 3)
В предыдущих статьях мы сравнили фильтрованные индексы и индексированные представления, поняв, в каких случаях каждый из них проявляет себя наилучшим образом.
Если вы пропустили Часть 2, вы можете прочитать её здесь:
👉 Фильтрованные индексы: сравнение производительности с примерами (Часть 2)
Сегодня мы добавляем в игру нового игрока.
Потому что, когда объём данных начинает расти… когда миллионы строк превращаются в десятки или сотни миллионов… мы получаем мощного нового союзника:
Колоночные индексы (Columnstore Indexes).
И это меняет всё.
8.3.26
Фильтрованные индексы: сравнение производительности с примерами (Часть 2)
Эта статья является продолжением предыдущего глубокого погружения в настройку производительности SQL Server!
Если вы пропустили Часть 1, вы можете прочитать её здесь:
Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)
В первой статье мы проанализировали, как фильтрованные индексы могут кардинально сократить логические чтения и оптимизировать планы выполнения.
Сегодня мы углубляемся и сравниваем фильтрованный индекс с индексированным представлением, используя практические, воспроизводимые SQL-скрипты.
Вы найдёте конкретные сценарии, которые сможете протестировать в своей собственной лаборатории — потому что настройка производительности — это не теория, это экспериментирование.
6.3.26
Анатомия задания очистки CDC в SQL Server (и как поддерживать его в рабочем состоянии)
Система отслеживания изменений данных (Change Data Capture, CDC) замечательна, пока не перестаёт ей быть. При высокой интенсивности изменений задание очистки CDC может начать отставать. Когда это происходит, таблицы изменений (Change Tables, CT) быстро разрастаются, а задание очистки может блокировать задание записи (capture job), что, в свою очередь, может задерживать или останавливать нижестоящие системы-потребители.
Эта статья объясняет: как быстро оценить рост таблиц изменений, как задание очистки на самом деле удаляет строки и три основных «рычага» настройки для поддержания стабильности CDC.
27.2.26
Как фильтрованные индексы кардинально улучшают производительность запросов (часть 1)
Сегодня мы погружаемся в мощную технику настройки производительности SQL Server, которая может кардинально сократить логические чтения, оптимизировать планы выполнения и значительно улучшить производительность запросов в реальных производственных средах.
Если вы работаете с Microsoft SQL Server и боретесь с медленными запросами, высокими логическими чтениями или неэффективными планами выполнения, эта продвинутая техника настройки производительности SQL Server может кардинально улучшить производительность запросов.
В этой статье мы проанализируем, как фильтрованные индексы в SQL Server могут уменьшить ввод-вывод, оптимизировать планы выполнения и значительно повысить производительность OLTP.
26.2.26
Обнаружение длинных цепочек IAM
В предыдущей статье Любопытный случай периодического сбоя запроса к крошечной таблице я описал проблему, с которой Джонатан столкнулся у клиента: очень длинные цепочки IAM и обстоятельства, к ним приведшие.
Вопрос заключался в том, как доказать, что некоторые единицы распределения имеют длину цепочки IAM, непропорциональную объёму данных в единице распределения, без утомительного прохода по каждой цепочке IAM, начиная с первой IAM-страницы (чей идентификатор всегда хранится во внутренней таблице sys.allocation_units).
11.2.26
У tempdb всегда должно быть по одному файлу данных на ядро процессора?
Этот миф я слышу снова, и снова, и снова…
У tempdb всегда должно быть по одному файлу данных на каждое ядро процессора.
ЛОЖЬ
Это один из самых разочаровывающих мифов, потому что существует так много «официальной» информации от Microsoft и других записей в блогах, которые увековечивают этот миф.
