Пишешь ли ты SQL запросы

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

Нужен не синтаксис, а эксплуатационный SQL. Инженеру приходится выяснять, что душит базу прямо сейчас, кто держит блокировку, доехала ли миграция и почему растёт диск. Ответ «знаю SELECT и JOIN» показывает, что к базе вы подходили только через приложение.

Как отвечать

Скажите, что пишете запросы в основном для диагностики, и назовите инструменты. В PostgreSQL это pg_stat_activity для активных и ждущих сессий, pg_locks для разбора блокировок, pg_stat_statements для топа запросов по суммарному времени, EXPLAIN (ANALYZE, BUFFERS) для конкретного плана, pg_stat_user_tables для мёртвых строк и работы автовакуума, pg_stat_replication для отставания реплики.

select pid, now() - query_start as duration, state, wait_event, left(query, 80)
from pg_stat_activity
where state <> 'idle' and now() - query_start > interval '5 minutes'
order by duration desc;

Отдельно проговорите аккуратность. Чтение системных представлений безопасно, а pg_terminate_backend, ручные UPDATE и DELETE по боевым данным делаются только с согласованием и всегда после SELECT с тем же условием. Доступ у инженера обычно отдельной ролью только на чтение, пароль из хранилища секретов, а не из истории шелла.

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

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

Отвечают перечислением операторов и на этом останавливаются. Вопрос от инженера эксплуатации почти всегда ведёт к диагностике, а не к синтаксису.

Второе: путают idle и idle in transaction. Простаивающее соединение безобидно, а зависшее в открытой транзакции держит блокировки и не даёт автовакууму убирать старые версии строк, диск растёт без видимой причины.

Третье: лечат медленный запрос индексом прямо в часы нагрузки обычным CREATE INDEX. Он блокирует запись в таблицу, нужен вариант CONCURRENTLY, который при этом не работает внутри транзакции и при сбое оставляет невалидный индекс.