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

А, ну это же классика, блядь! Разбор полётов по тормозным запросам — это как операция на открытом мозге, только вместо скальпеля у тебя EXPLAIN ANALYZE, а вместо пациента — твоя ебучья база данных, которая внезапно решила, что full scan таблицы на 10 миллионов строк — это отличная идея, в рот меня чих-пых!

Слушай сюда, расписываю по полочкам, как это у нормальных людей делается, а не как у того немого Герасима, который только «Му-му» мычать может, когда его про план запроса спросишь.

1. План — это всё, блядь! (Уровень SQL)

Тут главный царь и бог — это EXPLAIN / EXPLAIN ANALYZE. Это как рентген твоему запросу, ёпта. Он тебе вывалит всю подноготную: что, как и почём.

EXPLAIN ANALYZE 
SELECT * FROM orders WHERE user_id = 123 AND status = 'SHIPPED';

На что орать и материться, глядя в вывод:

• Seq Scan (последовательное сканирование) на большой таблице — это пиздец, а не операция. Это значит, база, как конь шахматный, тупо прошлась по всем строкам, вместо того чтобы взять индекс. Ядрёна вошь!
• Индексов нет там, где они должны быть — ну ты понял, кто тут мудак. Запрос ищет по user_id, а индекс на user_id и status вместе — хуй с горы.
• Дорогие операции типа Hash Join на лям записей или Sort (сортировка) без индекса — это верный признак, что запрос скоро накроется медным тазом под нагрузкой.

Ещё, блядь, в каждой базе свои закидоны: в PostgreSQL — pg_stat_statements (святая вещь, показывает самые жрущие запросы), в MySQL — Slow Query Log (лениво записывает, кто тормозит), в SQL Server — Query Store.

2. Смотрим, что творит твоё приложение (Уровень Java)

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

• Hibernate Statistics (hibernate.generate_statistics=true): Включаешь эту магию — и она тебе покажет такое... Например, классику жанра — проблему N+1. Ты запросил 100 заказов, а Hibernate, хитрая жопа, сделал 101 запрос: один для заказов, и по отдельному — для каждого пользователя в заказе. Удивление пиздец! Время выполнения — овердохуища.
• JDBC-прокси (типа p6spy): Ставишь эту прослойку — и она начинает логировать ВСЕ SQL-запросы, которые уходят в базу, с параметрами и временем выполнения. Иногда смотришь в лог и думаешь: «Сам от себя охуел, я это что, отправлял?».
• APM-инструменты (Datadog, New Relic): Это уже тяжёлая артиллерия. Они трассируют весь путь запроса от твоего контроллера, через сервисы, до самой базы. Наглядно показывают, где именно система просела: то ли в коде затупили, то ли запрос говном оказался.

3. Гоняем и проверяем под нагрузкой

Ну оптимизировал ты запрос, индекс накинул. А он в проде, под реальными данными и нагрузкой, как себя поведёт? Чтобы не было сюрпризов, надо его, сука, нагрузить.

• JMH (Java Microbenchmark Harness): Штука для микротестов. Хочешь проверить, насколько быстрее стал твой новый метод в репозитории? Запускаешь JMH — он тебе даст точные цифры, без погрешностей от сборки мусора и прочей хуйни.
• Gatling / JMeter: Это уже чтобы устроить маленький ад. Настраиваешь сценарий, где 1000 виртуальных пользователей одновременно тыкают в твой эндпоинт, и смотришь, как твой красивый оптимизированный запрос начинает захлёбываться и просить пощады. Если выдерживает — молодец. Нет — возвращайся к пункту 1, мудак.

Итоговый алгоритм, чтоб не распыляться:

1. Выявить врага: Через лог медленных запросов или APM находишь тот самый запрос, который всех тормозит.
2. Провести дознание: Суёшь его в EXPLAIN ANALYZE и смотришь план. Ищешь Seq Scan, отсутствие индексов и прочие преступления.
3. Применить пытки (оптимизацию): Добавляешь индекс, переписываешь запрос, фиксишь N+1.
4. Устроить проверку на прочность: Гоняешь оптимизированную версию под нагрузкой (Gatling) и сравниваешь метрики с тем, что было. Если стало лучше — красава. Если нет... ну, блядь, начинай сначала. Волнение ебать, но терпения ноль ебать — так и живём.