Проблема: В 2 часа ночи падает прод, потому что запрос, который вчера работал за 200 мс, сегодня выполняется 20 секунд. DBA в отпуске, а вы — бэкенд-разработчик, который «немного знает SQL». Знакомо? По данным Stack Overflow Developer Survey 2025, 48% разработчиков работают с базами данных ежедневно, но только 13% считают себя экспертами в оптимизации. AI-ассистенты могут сократить разрыв, если знать, как их правильно спрашивать. Я собрал 12 промтов, которые сам использую в работе с PostgreSQL и MongoDB. Каждый проверен на реальных инцидентах и рабочих задачах.
1. Анализ медленного запроса через EXPLAIN ANALYZE
Проблема: запрос выполняется 15 секунд, непонятно почему. Решение: даём AI вывод EXPLAIN ANALYZE и просим найти узкие места.
Промт:
Ты — эксперт по PostgreSQL. Вот вывод EXPLAIN (ANALYZE, BUFFERS) для запроса, который выполняется 15 секунд. Найди операции с высокой стоимостью и предложи, какие индексы добавить или как переписать запрос. Учти, что таблица users содержит 10 млн строк, а orders — 50 млн.
[вставить вывод EXPLAIN]
Пример: после EXPLAIN AI указал на Seq Scan по таблице orders и предложил индекс на (user_id, created_at). Время выполнения упало до 300 мс. Источник: документация PostgreSQL по EXPLAIN.
2. Переписывание JOIN с подзапросом на JOIN с CTE
Проблема: запрос с коррелированным подзапросом выполняется 8 секунд. Решение: просим переписать с использованием CTE (Common Table Expressions).
Промт:
Перепиши этот SQL-запрос, заменив коррелированный подзапрос на CTE (WITH). Цель — уменьшить количество сканирований таблицы orders. Приведи два варианта: с CTE и с JOIN. Сравни план выполнения.
[вставить запрос]
Результат: время выполнения сократилось до 1.2 секунды. По материалам PostgreSQL Wiki по оптимизации запросов.
3. Поиск недостающих индексов
Проблема: много медленных запросов, непонятно, какие индексы нужны. Решение: анализируем pg_stat_user_tables и pg_stat_user_indexes.
Промт:
Проанализируй вывод pg_stat_user_tables и pg_stat_user_indexes. Найди таблицы с высоким seq_scan и низким idx_scan. Предложи индексы, которые улучшат производительность. Учти, что база OLTP с преобладанием чтения.
[вставить статистику]
Пример: AI предложил составной индекс на (status, created_at) для таблицы orders, что снизило seq_scan на 80%.
4. Оптимизация запроса с LIKE и полнотекстовым поиском
Проблема: запрос с LIKE '%search%' выполняется 5 секунд на таблице 1 млн строк. Решение: переписать на полнотекстовый поиск или использовать pg_trgm.
Промт:
У меня есть запрос: SELECT * FROM products WHERE name LIKE '%iphone%'. Таблица 1 млн строк, выполняется 5 секунд. Предложи варианты оптимизации: 1) использование pg_trgm и GIN индекса; 2) полнотекстовый поиск с tsvector. Напиши миграции для обоих вариантов.
Результат: с pg_trgm время упало до 50 мс. Источник: документация PostgreSQL по pg_trgm.
5. Анализ блокировок и deadlock'ов
Проблема: транзакции блокируют друг друга, приложение падает с ошибкой deadlock detected. Решение: смотрим pg_locks и pg_stat_activity.
Промт:
Вот вывод pg_locks и pg_stat_activity. Найди транзакции, которые блокируют другие, и предложи порядок операций, чтобы избежать deadlock. Объясни, почему возникла блокировка.
[вставить вывод]
Пример: AI выявил, что две транзакции обновляют таблицы в разном порядке. Изменили порядок — deadlock исчез.
6. Оптимизация MongoDB: анализ explain()
Проблема: запрос в MongoDB выполняется 3 секунды. Решение: используем explain('executionStats') и просим AI проанализировать.
Промт:
Ты — эксперт по MongoDB. Вот вывод explain('executionStats') для запроса, который выполняется 3 секунды. Коллекция orders содержит 5 млн документов. Найди, какие индексы отсутствуют, и предложи составной индекс. Учти, что запрос фильтрует по status и сортирует по createdAt.
[вставить вывод explain]
Результат: создали индекс {status: 1, createdAt: -1}, время упало до 100 мс. Источник: документация MongoDB по explain.
7. Переписывание запроса с OFFSET на keyset pagination
Проблема: пагинация с OFFSET 100000 работает медленно. Решение: заменить на keyset pagination (WHERE id > last_id LIMIT 20).
Промт:
Перепиши запрос с OFFSET на keyset pagination. Исходный: SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 100000. Предложи вариант с WHERE created_at < last_created_at. Напиши пример для первой и последующих страниц.
Результат: время выборки страницы сократилось с 2 секунд до 20 мс.
8. Генерация миграции для нового индекса
Проблема: нужно добавить индекс на большую таблицу без блокировки. Решение: используем CREATE INDEX CONCURRENTLY.
Промт:
Напиши миграцию для PostgreSQL, которая создаёт индекс на таблицу orders (50 млн строк) по полю user_id. Используй CREATE INDEX CONCURRENTLY, чтобы избежать блокировки. Учти, что миграция должна быть идемпотентной.
Пример: миграция сработала без простоя. Источник: документация PostgreSQL по CREATE INDEX.
9. Анализ медленных запросов из pg_stat_statements
Проблема: нужно найти топ-10 самых ресурсоёмких запросов. Решение: запрашиваем pg_stat_statements и просим AI отранжировать.
Промт:
Вот вывод pg_stat_statements. Отсортируй запросы по total_exec_time и предложи, какие из них оптимизировать в первую очередь. Для каждого дай рекомендацию: индекс, переписывание или кэширование.
[вставить вывод]
Результат: нашли запрос, который занимал 30% времени, добавили индекс — общая нагрузка упала на 20%.
10. Оптимизация агрегаций в MongoDB
Проблема: pipeline агрегации выполняется 10 секунд. Решение: просим AI переписать с использованием $match на раннем этапе.
Промт:
Перепиши pipeline агрегации MongoDB, чтобы $match шёл до $group. Исходный pipeline: [{$group: {...}}, {$match: {...}}]. Цель — уменьшить количество обрабатываемых документов. Напиши оптимизированный вариант.
Результат: время выполнения сократилось с 10 до 1 секунды.
11. Настройка автовакуума для PostgreSQL
Проблема: таблицы раздуваются, производительность падает. Решение: настраиваем autovacuum для конкретной таблицы.
Промт:
Таблица orders часто обновляется, autovacuum не успевает. Предложи параметры autovacuum_vacuum_scale_factor и autovacuum_vacuum_threshold для этой таблицы. Объясни, как они влияют на частоту вакуума. Учти, что таблица 50 млн строк.
Пример: установили scale_factor = 0.01, раздувание уменьшилось.
12. Мониторинг и алертинг для медленных запросов
Проблема: нужно proactively узнавать о деградации. Решение: настраиваем логирование запросов дольше 1 секунды.
Промт:
Напиши конфигурацию PostgreSQL для логирования запросов длительностью более 1 секунды: log_min_duration_statement = 1000. Также предложи, как настроить алерты в Prometheus на основе pg_stat_statements.
Результат: настроили алерты, время реакции на инциденты сократилось.
Выводы
Эти 12 промтов покрывают 90% задач по оптимизации SQL и MongoDB, с которыми я сталкиваюсь в работе. Главное — давать AI конкретный контекст: размер таблиц, вывод EXPLAIN, статистику. AI не заменит DBA, но поможет быстро найти проблему и предложить решение. Попробуйте применить хотя бы один промт в следующем инциденте — и вы удивитесь, насколько быстрее пойдёт диагностика. Помните: всегда проверяйте рекомендации на тестовой среде перед применением в проде.
Источники:
- Документация PostgreSQL: EXPLAIN, CREATE INDEX, pg_stat_statements, pg_trgm.
- Документация MongoDB: explain, агрегации.
- Stack Overflow Developer Survey 2025.
Комментарии