Промты для DBA: ускоряем PostgreSQL и MongoDB без ручного переписывания SQL

Почему промты для баз данных — это новый SQL

В 2026 году разработчики всё чаще используют LLM не только для написания кода, но и для работы с базами данных. Однако универсальные промты вроде «напиши SQL-запрос» дают посредственный результат: модель не знает вашу схему, не учитывает особенности версии PostgreSQL или MongoDB, не оптимизирует план выполнения. Мы собрали 12 проверенных сценариев — от генерации сложных аналитических запросов до автоматизации миграций и проектирования схем. Каждый промт сопровождается задачей, примером и пояснением, почему он работает. Все примеры протестированы на PostgreSQL 16 и MongoDB 7.0.

Базовые промты: генерация и понимание запросов

1. Генерация SQL по текстовому описанию с учётом схемы

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

Промт:

Ты — эксперт по PostgreSQL 16. У меня есть таблицы:
users (id serial primary key, name text, email text unique, created_at timestamptz)
orders (id serial primary key, user_id int references users(id), amount numeric(10,2), status text, created_at timestamptz)
Напиши запрос: вывести имена пользователей и сумму их заказов за последние 30 дней, только для статусов 'paid' и 'shipped', отсортировать по убыванию суммы.

Пример результата:

SELECT u.name, SUM(o.amount) AS total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= NOW() - INTERVAL '30 days'
  AND o.status IN ('paid', 'shipped')
GROUP BY u.id, u.name
ORDER BY total DESC;

Почему работает: модель получает точную схему и версию СУБД, что исключает ошибки с типами и синтаксисом.

2. Объяснение чужого SQL-запроса

Задача: разобраться в сложном legacy-запросе.

Промт:

Объясни, что делает этот SQL-запрос, построчно. Укажи, какие индексы могли бы его ускорить.

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

3. Генерация MongoDB-запроса по описанию

Задача: создать запрос на языке агрегации MongoDB.

Промт:

Коллекция orders: { _id, userId, items: [{ productId, qty, price }], status, createdAt }
Напиши pipeline: для каждого пользователя посчитать общую сумму заказов со статусом 'completed' за 2026 год, вывести топ-10.

Пример результата:

db.orders.aggregate([
  { $match: { status: 'completed', createdAt: { $gte: ISODate('2026-01-01'), $lt: ISODate('2027-01-01') } } },
  { $unwind: '$items' },
  { $group: { _id: '$userId', total: { $sum: { $multiply: ['$items.qty', '$items.price'] } } } },
  { $sort: { total: -1 } },
  { $limit: 10 }
])

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

4. Анализ EXPLAIN ANALYZE

Задача: понять, почему запрос выполняется медленно.

Промт:

Вот вывод EXPLAIN (ANALYZE, BUFFERS) для запроса. Найди узкие места и предложи оптимизации: индексы, переписывание, настройки.
[вставить вывод]

Пример результата: модель указывает на Seq Scan по большой таблице, предлагает составной индекс и переписывание подзапроса в JOIN.

5. Создание оптимальных индексов

Задача: подобрать индексы под набор запросов.

Промт:

Даны 5 запросов к таблице orders (10 млн строк). Предложи минимальный набор индексов (B-tree, GIN, BRIN), обоснуй каждый. Учти, что есть частые INSERT.

Пример результата: рекомендация создать составной индекс (status, created_at) и частичный индекс для активных заказов, чтобы не замедлять вставку.

6. Оптимизация агрегаций в MongoDB

Задача: ускорить pipeline, который выполняется минуты.

Промт:

Мой pipeline делает $lookup и $group по 5 млн документов. Как ускорить? Предложи индексы, изменение порядка стадий, использование $merge.

Пример результата: вынос $match в начало, создание индекса по полю в $lookup, замена $group на $group с $sort перед ним.

Экспертные промты: миграции, схемы, транзакции

7. Генерация миграции с нулевым простоем

Задача: добавить колонку в большую таблицу без блокировки.

Промт:

PostgreSQL 16, таблица users 50 млн строк. Нужно добавить NOT NULL колонку с дефолтом. Напиши безопасную миграцию без долгой блокировки.

Пример результата: пошаговый план: добавить колонку без NOT NULL, заполнить батчами, создать constraint NOT VALID, затем VALIDATE.

8. Проектирование схемы MongoDB

Задача: выбрать между embedding и referencing.

Промт:

Проектирую БД для блога: посты, комментарии, лайки. Комментариев до 1000 на пост. Что лучше: встраивать комментарии в пост или отдельная коллекция? Обоснуй с учётом паттернов доступа.

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

9. Транзакции и уровни изоляции

Задача: избежать аномалий при конкурентном доступе.

Промт:

У меня есть транзакция, которая читает баланс и обновляет его. При нагрузке возникают гонки. Какой уровень изоляции выбрать в PostgreSQL? Напиши пример с SELECT FOR UPDATE.

Пример результата: рекомендация REPEATABLE READ или использование advisory locks, пример кода.

10. Резервное копирование и восстановление

Задача: настроить стратегию бэкапов.

Промт:

Нужно настроить ежедневный бэкап PostgreSQL 16 с PITR. Опиши шаги: pg_basebackup, архивация WAL, восстановление на точку во времени.

Пример результата: пошаговая инструкция с командами.

11. Рефакторинг схемы без потери данных

Задача: разделить таблицу или изменить тип.

Промт:

Хочу разбить таблицу orders на orders_current и orders_archive. Напиши план миграции с триггерами и без остановки приложения.

Пример результата: создание партиций, перенос данных, переключение через view.

12. Автоматизация рутинных операций

Задача: сгенерировать скрипты для мониторинга и обслуживания.

Промт:

Напиши SQL-запросы для мониторинга PostgreSQL: размеры таблиц, bloat, долгие запросы, блокировки. И скрипт для MongoDB: статистика коллекций, медленные операции.

Пример результата: набор готовых запросов для pg_stat_statements и db.currentOp().

Как внедрять промты в рабочий процесс

Используйте эти промты как шаблоны, адаптируя под свою схему и версию СУБД. Всегда проверяйте сгенерированный код на тестовой среде. Помните: LLM не заменяет DBA, но ускоряет рутину и помогает находить неочевидные решения. Начните с базовых сценариев, постепенно переходя к экспертных — и вы заметите, как меньше времени уходит на написание SQL и больше — на архитектуру и бизнес-логику.