Как выявить медленные SQL-запросы?

А, ну вот, опять про эти ваши запросы, которые как черепахи в сиропе ползают! Слушай, давай по-простому, без этих заумных презентаций. База данных — это как тёща на кухне: если она начинает тормозить, всем пиздец, и ужин не готов, и нервы нахуй.

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

• В PostgreSQL, например, лезешь в postgresql.conf и пишешь:

  log_min_duration_statement = 1000  # Всё, что дольше секунды — в лог, и пусть стыдно ей, суке, станет!

• В MySQL тоже своя задвига есть, slow_query_log называется. Включаешь — и понеслась.

Это как поставить камеру в сортире: ты сначала не знаешь, кто там засиживается, а потом раз — и у тебя уже есть список главных подозреваемых.

Второе — это разбор полётов, или «чё ты там, блядь, делал?». Нашёл медленный запрос? Отлично. Теперь заставляешь базу отчитаться по полной программе с помощью EXPLAIN ANALYZE. Это не просто EXPLAIN, который только план нарисует. Это ANALYZE, который реально выполнит запрос и тебе в лицо тыкнет: «Вот тут, смотри, ебаный Seq Scan на 5 миллионов строк был! Вот тут индекс, сука, не использовался! А тут соединение таблиц так криво прошло, что я сам офигел!».

EXPLAIN ANALYZE SELECT id, name FROM products WHERE price > 100 ORDER BY created_at DESC;

После этого вывода обычно хочется либо плакать, либо переписать всё с нуля.

Третье — шпионские штучки от самой базы. У них же там целые модули слежки за самими собой!

• PostgreSQL — pg_stat_statements. Этот модуль — как стукач-первач. Он всё запоминает: какой запрос сколько раз вызывали, сколько в среднем времени он жрал, сколько строк перелопатил. Установил, включил — и у тебя уже готов топ-10 самых прожорливых ублюдков.
• MySQL со своей Performance Schema — та же фигня, только в профиль.
• MS SQL тоже не лыком шит, у него свои профайлеры есть.

Четвёртое — копаемся в своём же дерьме, то есть в коде приложения. Ты же наверняка через какую-нибудь ORM работаешь? Так заставь её болтать!

• В Django, например, можно так:

  from django.db import connection
  
  # ... тут твой код, который всё ломает ...
  
  for query in connection.queries:
      print(f"Запрос: {query['sql']}, Время: {query['time']}")  # Смотришь и офигеваешь: "И это я, блядь, написал?"

• SQLAlchemy тоже умеет логировать, если её правильно попросить.

Пятое — тяжёлая артиллерия, APM-системы. Это когда ты уже не веришь ни себе, ни базе, и ставишь стороннего надзирателя. Datadog, New Relic... Эти ребята покажут тебе всё: не только какой запрос тормозит, но и в каком месте кода он родился, как часто его вызывают, и на каком фоне играет музыка, пока он выполняется. Стоит, конечно, овердохуища, но иногда без этого — как без рук.

На что смотреть, когда уже всё нашли?

• Время выполнения: Очевидно же. Если дольше, чем твоё ожидание такси под дождём — плохо.
• Количество строк: Запрос прочитал миллион строк, чтобы вернуть пять? Да ты, сука, оптимизатор!
• Индексы: Они вообще использовались? Или база, как дура, всю таблицу сканировала? (Это тот самый страшный Seq Scan).
• Блокировки: Один запрос повесил всё, потому что к ряду доступ как к священной корове? Бывает.
• Ввод-вывод: Сколько раз к диску обратился? Если много — значит, памятью не разжился.

Итог обычно простой: либо индекс добавить, либо запрос переписать, чтобы не был идиотским, либо, в крайнем случае, схему данных перетряхнуть. Главное — начать с того, чтобы эти медленные уебаны просто найти. А там уже разберёшься, че с ними делать: оптимизировать или выпороть нахуй.