Аудит SQL и производительности базы данных

Один и тот же экран открывается быстро утром и зависает во время загрузки каталога. Отчёт, который работал на тестовой базе, перестаёт укладываться в ожидание после роста истории. Для таких проблем нужен профиль конкретной операции с её данными и конкурирующей работой.

От наблюдения к запросу

Сначала определяем, что именно замедляется: просмотр карточки, поиск, запись заказа, импорт или построение сводки. Сопоставляем время приложения с работой базы. Причина может находиться вне SQL — например, в последовательных сетевых вызовах. В таком случае прямо указываем, почему изменение индекса не устранит задержку.

Для анализа используем доступные планы выполнения, журнал медленных запросов, размеры таблиц и сведения об индексах. Проверяем количество обращений к базе на одну пользовательскую операцию. Несколько сотен коротких запросов могут давать большую суммарную задержку, хотя ни один отдельно не выглядит тяжёлым.

Индекс полезен только в контексте нагрузки

Рассматриваем селективность, условия фильтрации, сортировку и связь таблиц. Учитываем цену записи и хранения: добавление индекса ко всем полям не является универсальной оптимизацией. Изменение схемы должно соответствовать реальным запросам и поддерживаемой версии СУБД.

Чтение

Избыточная выборка, повторяющиеся обращения, тяжёлая сортировка и несоответствие индексов запросу.

Запись

Длительные транзакции, конфликтующие обновления, блокировки и конкурентная обработка.

Рост истории

Накопление журналов и архивных объектов, изменение распределения данных и режима обслуживания.

Для проверки гипотез выбираем безопасную среду и характерный объём. Копия с несколькими строками не воспроизводит поведение большой базы. Производственные изменения, построение тяжёлых индексов и нагрузочные эксперименты обсуждаются отдельно с владельцем эксплуатации.

Как подтвердить улучшение

Сохраняем исходный сценарий и условия замера. После предложенного изменения сравниваем тот же результат, а не только длительность запроса: ускорение не должно терять записи, менять порядок или нарушать границы доступа. Отдельно смотрим поведение во время фонового обмена и параллельных пользовательских операций.

В заключении указываем подтверждённые причины, приоритеты и условия применения рекомендаций. Например, где достаточно изменить запрос, где нужна миграция, а где сначала требуется наблюдение. Оценка учитывает окно работ и восстановление; длительная операция изменения схемы не становится безопасной только от того, что занимает одну строку SQL.

Начать можно с описания медленного действия, версии СУБД и обезличенного запроса либо диагностической выгрузки. Пароли рабочих пользователей и полный дамп не требуются по умолчанию. Если данных недостаточно для вывода, предлагаем конкретное измерение, которое поможет проверить гипотезу.