<b>Как быстро найти bottleneck: сначала мониторинг, потом индексы</b>

<b>Как быстро найти bottleneck: сначала мониторинг, потом индексы</b>

Коллеги, давайте разберем план выполнения. Узкое место почти всегда видно раньше, чем его начинают «лечить» индексом: растет latency, очередь запросов, CPU, disk wait или lock wait. Ищем не «медленную базу», а конкретную точку, где система теряет время.

Схема простая, но дьявол кроется в статистике. Смотрите по слоям:
— приложение: всплеск времени ответа, ретраи, таймауты;
— БД: рост активных сессий, long-running queries, блокировки;
— хранилище: IOPS, throughput, await, cache miss;
— память: вытеснение буферов, spill на диск, рост temp usage.

Потом связываем симптомы с конкретным запросом. Если CPU высокий — ищем тяжелые сканы, сортировки, hash join; если I/O — проверяем большие чтения, плохую селективность, отсутствие covering-индексов; если lock wait — смотрим, кто держит транзакцию и почему она живет слишком долго. В продакшене так лучше не делать, и вот почему: чинить надо причину, а не следствие.

Золотое правило: сначала мониторинг, потом индексы. Без базовой картины вы легко оптимизируете не тот запрос и получите красивый план, который все равно упирается в диск или блокировки.