В большинстве заданий SQL Server, расписаний и скрытых сложностей гораздо больше, чем вы осознаёте. И только когда вы подходите к миграции и заглядываете под капот, масштаб становится очевидным.
Здесь мы извлечём детали из базы данных msdb, чтобы получить чёткое представление о том, с чем вам на самом деле предстоит иметь дело. Если вы не поймёте объём работ заранее, миграция сама выявит все сложности.
Несколько человек предложили разобрать некоторые мифы, связанные с контрольными суммами страниц, так что сегодня у нас очередной экстравагантный «многомифобойный» день! Ну, по крайней мере, я в восторге :-)
Я подробно описывал контрольные суммы страниц в статье блога How to tell if the IO subsystem is causing corruptions?
уверен, что это случится с вами в какой-то момент... и с множеством ваших коллег также. Клиент сообщает вам, что ваше приложение работает крайне медленно. Вы уже идентифицировали проблемный запрос и…
Исполнение плана выглядит идеально…
но ваш запрос всё ещё медленно работает.
👉 Что-то лжёт вам.
И нет… не SQL Server! ....это то, как вы читаете план выполнения.
👉 Если вы пропустили мою предыдущую статью, ознакомьтесь с ней здесь: Прекратите дефрагментировать индексы! Доступна для предварительного изучения функция Auto Index Compaction
Ваш запрос работает медленно.
И вы добавляете индекс.
Запрос ускоряется… на мгновение.
Но затем всё остальное начинает работать медленнее.
👉 Что же произошло?
Возможно, вы перегружаете свою базу данных индексами.
Существует огромное количество лучших практик по настройке производительности SQL Server — я мог бы легко написать целую книгу на эту тему, особенно учитывая множество различных настроек базы данных, настроек сервера, практик написания кода, типов ожидания и так далее, которые могут влиять на производительность. Для этой статьи я решил немного отступить от списка конкретных деталей и дать несколько общих рекомендаций о том, как подходить к настройке производительности, чтобы максимизировать усилия и минимизировать отвлекающие факторы.
В предыдущей статье мы проанализировали улучшения производительности в SQL Server 2025 CU3 и обнаружили скрытые оптимизации, о которых никто не говорит.
👉 Если вы пропустили, посмотрите здесь:
SQL Server 2025 CU3 – Скрытое улучшение производительности, о котором никто не говорит
В этой же статье мы представим удивительную новость в мире SQL Server, которую я называю функцией автоматического уплотнения индексов (Auto Index Compaction).
Существует множество вещей, которые я постоянно слышу о том, что может и что не может восстановление (repair), что может вызывать повреждения и могут ли повреждения исчезать. Некоторые из них я уже описывал в постах за последние несколько лет, поэтому вместо того, чтобы повторять то же самое, этот пост-разоблачитель представляет собой несколько интересных ссылок, чтобы порадовать вас.
У Джонатана недавно возникла проблема у клиента: буферный пул SQL Server был принудительно уменьшен до абсурдно маленького размера — всего несколько сотен мегабайт, но при этом в операционной системе также практически не было свободной памяти. Page Life Expectancy (ожидаемое время жизни страницы) был равен нулю! Что же происходило?
Индексы — одна из самых мощных функций производительности в SQL Server. Но они также одни из самых непонятых. Многие разработчики считают, что добавление новых индексов автоматически улучшает производительность. К сожалению, часто бывает наоборот. Одна из самых распространённых проблем с производительностью SQL Server, которую я вижу в реальных системах, — это база данных, полная ненужных или плохо спроектированных индексов. Сегодня мы рассмотрим самую распространённую ошибку индексирования в SQL Server и способ её исправления.
Эта статья не для тех, кто уже использует Claude Code. Я не хочу слышать жалобы от пользователей Code в комментариях о том, что я не осветил ту или иную функцию или сценарий. Это общий обзор на ~2000 слов о том, что это такое, почему вы можете этого захотеть, что вам нужно будет обсудить с вашей командой, и куда обращаться за дополнительной информацией.
Я также должен упомянуть, что я использую множество маркированных списков в своих обычных текстах. Как и во всех моих постах, ничего из этого не написано с помощью ИИ, точка. Эти слова исходят непосредственно из моего затуманенного алкоголем мозга, написаны в марте 2026 года, и, несомненно, со временем эта информация потеряет актуальность.
(Эта статья впервые появился на SQLperformance.com четыре года назад как часть серии блогов, до того как этот сайт был закрыт позднее в 2022 году, а серия была прервана. Переопубликовано здесь с разрешения, с небольшими правками.)
Во второй части этой серии я описал структурную иерархию журнала транзакций. Поскольку эта статья в основном касается описанных мной виртуальных файлов журнала (VLF), я рекомендую вам прочитать вторую часть, прежде чем продолжить.
Когда всё хорошо, журнал транзакций будет бесконечно циклически повторяться, повторно используя существующие VLF. Это поведение я называю циклической природой журнала. Однако иногда происходит что-то, что мешает этому, и журнал транзакций растёт и растёт, добавляя всё больше и больше VLF. В этой статье я объясню, как всё это работает, и почему иногда и не работает.
Это не теория.
Это не лабораторная настройка.
Это произошло с реальной рабочей нагрузкой.
Исходное время выполнения: 42 секунды.
После оптимизации: 9.8 секунды.
Никакого нового индекса.
Никакого изменения схемы.
Никакого обновления оборудования.
Просто понимание того, как работает движок.
Приятного чтения — давайте заставим SQL Server летать.
Продолжение серии статей, вот предыдущая: Всё ещё о Batch Mode… Параметры совместимости и опции запросов (Часть 6)
