На этой неделе я вёл курс «Microsoft Certified Masters – Database» здесь, в Редмонде, и в первый день мы обсуждали структуру каталогов FILESTREAM. Мне задали вопрос: откуда берутся GUID имён каталогов? Поэтому я начал копаться в системных таблицах, пока Кимберли читала лекцию. Посмотрите мою предыдущую статью блога (Структура каталога FILESTREAM) за прошлую неделю, чтобы увидеть схему базы данных, с которой я работаю. Я воссоздал её снова и написал несколько запросов, чтобы найти, где хранятся GUID, поскольку они должны где-то храниться в базе данных.
4.4.26
Структура каталогов FILESTREAM – откуда берутся GUID?
3.4.26
SQL Server Parameter Sniffing: ошибка, которая не является ошибкой (но всё ломает)
В этой статье вы узнаете, как выявить и победить нестабильную производительность в SQL Server. Если ваши запросы без предупреждения переходят от «молниеносных» к «еле ползущим», вы стали жертвой Parameter Sniffing. Пришло время вернуть контроль над вашими планами выполнения и остановить непредсказуемость.
Ваш запрос работает быстро, а затем внезапно… становится медленным!
У вас есть:
- Тот же запрос.
- Те же данные.
- Тот же сервер.
👉 Что изменилось?
💣 Parameter Sniffing. И нет… это НЕ ошибка. Это то, как SQL Server был спроектирован для работы.
2.4.26
SQL Server Deprecated Features: 25-летняя хронология и руководство по обеспечению совместимости с будущими версиями
За последние 25 лет Microsoft SQL Server значительно эволюционировал, внедряя мощные инструменты и функциональные возможности, одновременно отказываясь от других. В рамках этой эволюции многие возможности были помечены как устаревшие — они по-прежнему работают в текущих версиях, но планируются к удалению в будущих выпусках. Понимание этих устаревших возможностей имеет решающее значение для администраторов баз данных и разработчиков, чтобы обеспечить долгосрочную совместимость и избежать потенциальных сбоев в своих системах.
Объявление возможности устаревшей служит сигналом от Microsoft о необходимости перехода от устаревших или менее эффективных технологий к современным альтернативам. От изменений синтаксиса до целых компонентов — в каждой версии SQL Server появлялись возможности, которые выходили из употребления по мере адаптации платформы к новым отраслевым стандартам и потребностям пользователей. Этот непрерывный процесс помогает поддерживать надёжную, безопасную и высокопроизводительную среду баз данных, но требует проактивного планирования, чтобы избежать зависимости от инструментов, которые вскоре станут неактуальными.
В этой статье мы рассмотрим подробную хронологию устаревших возможностей в различных версиях SQL Server, начиная с SQL Server 2000 и заканчивая последними выпусками. Изучив эти изменения, вы сможете лучше подготовиться к обновлениям, реорганизовать устаревший код и принять рекомендуемые практики, чтобы сохранить вашу инфраструктуру баз данных готовой к будущему. Давайте углубимся в ключевые возможности, которые были исключены за эти годы, и разберёмся с их заменами.
1.4.26
Аудит заданий агента перед миграцией
В большинстве заданий SQL Server, расписаний и скрытых сложностей гораздо больше, чем вы осознаёте. И только когда вы подходите к миграции и заглядываете под капот, масштаб становится очевидным.
Здесь мы извлечём детали из базы данных msdb, чтобы получить чёткое представление о том, с чем вам на самом деле предстоит иметь дело. Если вы не поймёте объём работ заранее, миграция сама выявит все сложности.
31.3.26
Мифы о контрольных суммах страниц
Несколько человек предложили разобрать некоторые мифы, связанные с контрольными суммами страниц, так что сегодня у нас очередной экстравагантный «многомифобойный» день! Ну, по крайней мере, я в восторге :-)
Я подробно описывал контрольные суммы страниц в статье блога How to tell if the IO subsystem is causing corruptions?
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).
24.3.26
Мифы для администратора SQL Server о повреждениях и восстановлении
Существует множество вещей, которые я постоянно слышу о том, что может и что не может восстановление (repair), что может вызывать повреждения и могут ли повреждения исчезать. Некоторые из них я уже описывал в постах за последние несколько лет, поэтому вместо того, чтобы повторять то же самое, этот пост-разоблачитель представляет собой несколько интересных ссылок, чтобы порадовать вас.
22.3.26
Самая распространённая ошибка индексирования в SQL Server (и как её исправить)
Индексы — одна из самых мощных функций производительности в SQL Server. Но они также одни из самых непонятых. Многие разработчики считают, что добавление новых индексов автоматически улучшает производительность. К сожалению, часто бывает наоборот. Одна из самых распространённых проблем с производительностью SQL Server, которую я вижу в реальных системах, — это база данных, полная ненужных или плохо спроектированных индексов. Сегодня мы рассмотрим самую распространённую ошибку индексирования в SQL Server и способ её исправления.
20.3.26
Использование Claude Code с SQL Server
Эта статья не для тех, кто уже использует Claude Code. Я не хочу слышать жалобы от пользователей Code в комментариях о том, что я не осветил ту или иную функцию или сценарий. Это общий обзор на ~2000 слов о том, что это такое, почему вы можете этого захотеть, что вам нужно будет обсудить с вашей командой, и куда обращаться за дополнительной информацией.
Я также должен упомянуть, что я использую множество маркированных списков в своих обычных текстах. Как и во всех моих постах, ничего из этого не написано с помощью ИИ, точка. Эти слова исходят непосредственно из моего затуманенного алкоголем мозга, написаны в марте 2026 года, и, несомненно, со временем эта информация потеряет актуальность.
18.3.26
Журнал транзакций SQL Server. Часть 3: Циклическая природа
(Эта статья впервые появился на SQLperformance.com четыре года назад как часть серии блогов, до того как этот сайт был закрыт позднее в 2022 году, а серия была прервана. Переопубликовано здесь с разрешения, с небольшими правками.)
Во второй части этой серии я описал структурную иерархию журнала транзакций. Поскольку эта статья в основном касается описанных мной виртуальных файлов журнала (VLF), я рекомендую вам прочитать вторую часть, прежде чем продолжить.
Когда всё хорошо, журнал транзакций будет бесконечно циклически повторяться, повторно используя существующие VLF. Это поведение я называю циклической природой журнала. Однако иногда происходит что-то, что мешает этому, и журнал транзакций растёт и растёт, добавляя всё больше и больше VLF. В этой статье я объясню, как всё это работает, и почему иногда и не работает.
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, и углубимся в изучение пакетного режима для строчного хранения.
Накопительный пакет обновлений для SQL Server 2022 CU24 - KB5080999
Описание: KB5080999
Скачать: SQLServer2022-KB5080999-x64.exe
Дата выпуска: 12 марта 2026 г.
SQL Server 2022 — Версия: 16.0.4245.2
Накопительный пакет обновления 3 для SQL Server 2025 - KB5077896
Описание: KB5077896
Скачать: SQLServer2025-KB5077896-x64.exe
Дата выпуска: 12 марта 2026 г.
SQL Server 2025 — Версия: 17.0.4025.3
12.3.26
Без новых индексов или изменений схемы - запросы быстрее в 10 раз с Batch Mode для Rowstore (Часть 4)
Надеюсь, вам нравится эта серия. Я искренне верю, что она может быть очень полезной для тех, кто профессионально использует SQL Server, как это делаю я уже более 20 лет (как летит время!).
Сегодня мы поговорим о пакетном режиме для строчного хранения (Batch Mode on Rowstore) и о том, как сделать ваш запрос в 10 раз быстрее без добавления каких-либо индексов.
Что ж... в Части 3 мы представили колоночные индексы и увидели, как выполнение в пакетном режиме может кардинально улучшить аналитические запросы.
Если вы пропустили предыдущую часть, вы можете прочитать её здесь:
Но вот в чём поворот.
Начиная с SQL Server 2019, вам не всегда нужен колоночный индекс, чтобы получить производительность пакетного режима.
SQL Server может активировать пакетный режим для строчного хранения.
И иногда... как я сказал вам в начале этой статьи... ваш запрос становится в 5 или 10 раз быстрее без добавления ни одного индекса. Поэтому я предлагаю вам продолжить чтение...
