PostgreSQL и MongoDB под прицелом AI: 11 промтов, которые превращают медленные запросы в молниеносные

PostgreSQL и MongoDB под прицелом AI: 11 промтов, которые превращают медленные запросы в молниеносные

Медленный запрос в проде — это не просто раздражающий лог. Это упавший SLA, разгневанный клиент и ночной созвон в 3 утра. По данным документации PostgreSQL, планировщик выбирает план выполнения на основе статистики, собранной командой ANALYZE, и если статистика устарела — вы получаете seq scan там, где нужен index scan. В MongoDB ситуация не лучше: неверно спроектированная схема или отсутствие составного индекса превращают find() в полный перебор коллекции.

Хорошая новость: LLM-агенты научились читать EXPLAIN ANALYZE, подсказывать индексы и даже предлагать миграцию схемы. Плохая новость: без точного промта вы получите общие советы вроде «добавьте индекс». Эта подборка — набор проверенных формулировок, которые заставляют AI работать как опытный DBA.

Ниже — 11 сценариев: от диагностики медленных запросов до проектирования схем без боли. Все примеры используют реальный синтаксис PostgreSQL 16 и MongoDB 7.0. Ссылки на официальные источники прилагаются.

1. Диагностика медленного запроса через EXPLAIN ANALYZE

Проблема: запрос выполняется 8 секунд, непонятно почему.

Промт:

Ты — эксперт по PostgreSQL. Вот вывод EXPLAIN (ANALYZE, BUFFERS) для запроса:
<paste plan>
Проанализируй: где planner недооценил cardinality, какие узлы дают
наибольший actual time, есть ли seq scan по большой таблице.
Предложи конкретные индексы (с типом: btree, gin, brin) и перепиши запрос.

Результат: AI указывает на узкое место — например, Hash Join с оценкой 1 row вместо 50 000 — и предлагает CREATE INDEX CONCURRENTLY.

2. Генерация правильных индексов под workload

Проблема: таблица на 50 млн строк, запросы фильтруют по 3 колонкам.

Промт:

У меня таблица orders(user_id, status, created_at, amount).
Основные запросы:
1) WHERE user_id = ? AND status = ? ORDER BY created_at DESC
2) WHERE status = ? AND created_at > ?
Предложи минимальный набор индексов (составные + частичные),
объясни порядок колонок и почему.

Результат: AI предложит (user_id, status, created_at DESC) и частичный WHERE status = 'pending' — меньше размер, быстрее запись.

3. Переписывание N+1 в один запрос

Проблема: ORM генерирует сотни запросов.

Промт:

Вот код на SQLAlchemy с N+1 проблемой:
<paste code>
Перепиши через joinedload/selectinload или через один SQL с JOIN.
Покажи EXPLAIN до и после.

Результат: вместо 500 запросов — один с LEFT JOIN LATERAL.

4. Проектирование схемы MongoDB под реальные запросы

Проблема: данные свалены в одну коллекцию, запросы тормозят.

Промт:

Спроектируй схему MongoDB для блога: users, posts, comments, likes.
Паттерны доступа:
- лента постов с автором (10 последних)
- комментарии к посту с лайками
Используй Extended Reference Pattern и Bucket Pattern где уместно.
Объясни, почему embedding лучше referencing в каждом случае.

Результат: AI предложит embed автора в пост (данные редко меняются) и bucket для лайков.

5. Агрегационный pipeline вместо хаоса

Проблема: 5 отдельных find() вместо одного pipeline.

Промт:

Перепиши этот код MongoDB на один aggregation pipeline:
<paste code>
Используй $match в начале, $lookup только при необходимости,
добавь $facet для параллельных агрегаций. Проверь через explain('executionStats').

Результат: один round-trip к БД вместо пяти.

6. Аудит блокировок и deadlocks в PostgreSQL

Проблема: транзакции падают с deadlock detected.

Промт:

Вот лог deadlock из PostgreSQL:
<paste log>
Объясни порядок захвата блокировок, предложи порядок операций,
чтобы избежать цикла. Рассмотри advisory locks как альтернативу.

Результат: AI покажет, что две транзакции захватывают строки в разном порядке, и предложит сортировку по id.

7. Партиционирование большой таблицы

Проблема: таблица логов на 500 ГБ, VACUUM не успевает.

Промт:

Предложи стратегию партиционирования для таблицы logs(id, created_at, level, message)
с 500 ГБ данных. Сравни RANGE по created_at и HASH по id.
Покажи DDL для декларативного партиционирования PostgreSQL 16.

Результат: AI выдаст PARTITION BY RANGE (created_at) с помесячными партициями.

8. Настройка autovacuum под нагрузку

Проблема: bloat растёт быстрее, чем vacuum.

Промт:

Таблица с интенсивным UPDATE (10k/сек). Дефолтный autovacuum не справляется.
Предложи настройки per-table: autovacuum_vacuum_scale_factor,
autovacuum_vacuum_cost_limit. Объясни trade-off с I/O.

Результат: конкретные ALTER TABLE ... SET (...) вместо глобальных изменений.

9. Миграция схемы без downtime

Проблема: нужно добавить NOT NULL колонку в таблицу на 100 млн строк.

Промт:

Составь план zero-downtime миграции: добавить колонку email NOT NULL UNIQUE
в таблицу users (100 млн строк) в PostgreSQL 16.
Разбей на этапы: ADD COLUMN NULL → backfill батчами → UNIQUE INDEX CONCURRENTLY → SET NOT NULL.
Покажи SQL для каждого этапа.

Результат: пошаговый план без блокировки таблицы.

10. Оптимизация MongoDB через индексы и covered queries

Проблема: find() возвращает документы полностью, читает диск.

Промт:

Запрос: db.users.find({country: 'DE', age: {$gt: 18}}, {name: 1, email: 1, _id: 0})
Предложи индекс, который сделает его covered query.
Проверь через .explain('executionStats') — должен быть IXSCAN без FETCH.

Результат: индекс {country: 1, age: 1, name: 1, email: 1} — данные читаются прямо из индекса.

11. Сравнение подходов: SQL vs NoSQL под задачу

Проблема: неясно, что выбрать для нового сервиса.

Промт:

Сервис: аналитика событий, 1 млрд событий/месяц, запросы — агрегации по времени и user_id.
Сравни PostgreSQL (с партиционированием) и MongoDB (time series collections).
Дай таблицу: скорость записи, скорость агрегаций, стоимость хранения, сложность операций.

Результат: обоснованный выбор с учётом time series коллекций MongoDB 7.0.

Сводная таблица сценариев

Официальные источники

• PostgreSQL 16 Documentation: EXPLAIN, Partitioning
• MongoDB 7.0 Manual: Aggregation Pipeline, Time Series
• Markus Winand, «Use The Index, Luke» — практическое руководство по индексам SQL
• Use of pg_stat_statements для поиска топ-запросов по total_time

Все 11 промтов — шаблоны. Замените <paste plan> на реальный вывод, и AI превратится в вашего напарника-DBA. Начните с промта №1: он даёт максимальный эффект за минимум времени и сразу показывает, где именно теряются секунды.