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

Что проверяют

Умеете ли вы находить причину медленного запроса по плану выполнения, а не наугад переписывать SQL. Для дата-специальностей это ещё и вопрос о движке: Postgres, ClickHouse, Spark и облачные хранилища оптимизируются по-разному. Следом обычно просят разобрать план конкретного запроса или рассказать про самый тяжёлый случай.

Как отвечать

Назовите движки, с которыми работали, и инструменты для каждого:

• PostgreSQL: EXPLAIN (ANALYZE, BUFFERS) для фактического плана, pg_stat_statements для поиска самых дорогих запросов, auto_explain для записи планов медленных запросов в лог;
• ClickHouse: таблица system.query_log со временем, прочитанными строками и памятью, EXPLAIN indexes = 1 для проверки, отсекает ли первичный ключ гранулы;
• Spark: Spark UI со стадиями и перекосом задач, df.explain("formatted"), адаптивное выполнение запросов (AQE), broadcast join для маленьких таблиц;
• облачные хранилища: объём просканированных данных как главная метрика, партиционирование и кластеризация.

Методы оптимизации тоже называйте по делу: фильтр по ключу партиции, чтобы сработало отсечение, проталкивание предикатов в Parquet, только нужные колонки вместо SELECT *, индексы и частичные индексы в OLTP, материализованные представления и предагрегаты для повторяющихся отчётов, борьба с перекосом ключей через соль или отдельную обработку горячих значений.

Пример приводите свой: какой был запрос, что показал план, что изменили и во сколько раз ускорилось. Если опыта с каким-то движком нет, скажите, где работали, и не приписывайте себе остальное.

Где спотыкаются

Путают EXPLAIN и EXPLAIN ANALYZE. Первый показывает оценку планировщика, второй реально выполняет запрос, и на DELETE или UPDATE без транзакции с откатом это уже изменение данных.

Переносят привычки OLTP в аналитику: пытаются ускорить ClickHouse как Postgres, добавляя индексы, хотя главное там сортировка таблицы ORDER BY и ключ партиционирования.

Смотрят только на время выполнения. Без прочитанных строк, объёма данных и перекоса по задачам непонятно, где на самом деле узкое место.