Мониторинг не лечит тормоза: как быстро найти узкое место в базе
Коллеги, давайте разберем план выполнения. Узкое место редко живет в одном месте: чаще это связка CPU, I/O, блокировки и плохой план. Поэтому первый шаг — не «добавить индекс», а посмотреть, где база реально тратит время: ожидание диска, конкуренция за latch, очередь на CPU или блокировки.
Рабочий порядок такой:
— сначала снимите топ ожиданий и утилизaцию ресурсов;
— потом найдите запросы с максимальным временем/логическими чтениями;
— отдельно проверьте блокировки и долгие транзакции;
— сравните план с фактом: если оценка резко расходится, виновата статистика или неудачный join.
Если запрос «тяжелый» только на бумаге, ищите селективность, перекос данных и сканы вместо seeks. Если система тормозит вся целиком, смотрите шире: переполненный пул соединений, очередь на запись, tempdb/temporary space, contention на горячих страницах. Схема простая, но дьявол кроется в статистике: один и тот же SQL может быть быстрым утром и мертвым под нагрузкой.
Золотое правило: сначала мониторинг, потом индексы. Иначе вы лечите симптом, а не bottleneck — и потом удивляетесь, почему «ускорение» добавило еще один дедлок.
Оптимизация производительности баз
@database_performance_tuning_arb
Мониторинг не лечит тормоза: как быстро найти узкое место в базе
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.