SQL, PostgreSQL и MongoDB под управлением ИИ: 12 промтов, которые ускорят запросы и обезопасят миграции в 2026 году
Представьте: вы смотрите на EXPLAIN ANALYZE, видите Seq Scan на таблице с 50 миллионами строк, а дедлайн — вчера. Или нужно перелить продакшн-базу PostgreSQL на новую версию без единой секунды простоя, и каждая ошибка грозит блокировкой таблиц. Знакомо? В 2026 году LLM уже не просто пишут код — они стали полноценными ассистентами DBA и бэкенд-разработчика. Но магия происходит не от «напиши мне запрос», а от правильно составленного промта.
Я собрал 12 проверенных шаблонов, которые сам использую в работе с PostgreSQL 17, MongoDB 8.0 и облачными managed-базами. Каждый промт — это готовый сценарий: от диагностики медленных запросов до миграции схемы без даунтайма. Вы можете копировать их как есть и адаптировать под свои таблицы.
Почему это работает? LLM обучены на миллионах строк SQL-кода, документации и issue-трекеров. Если дать им точный контекст (версию СУБД, структуру таблиц, план запроса), они выдают решения уровня senior-инженера. Главное — не спрашивать абстрактно, а следовать формуле: роль + контекст + задача + ограничения + формат вывода. Все промты ниже построены по этому принципу.
1. Диагностика медленного запроса: превращаем EXPLAIN в план действий
Задача: У вас есть запрос, который выполняется 12 секунд. Вы сняли EXPLAIN (ANALYZE, BUFFERS), но не понимаете, где узкое место.
Промт:
Ты — эксперт по оптимизации PostgreSQL 17. Проанализируй план выполнения запроса и предложи конкретные шаги по ускорению.
Контекст:
- Таблицы: orders (id, user_id, created_at, total, status), users (id, email, created_at)
- Индексы: orders_pkey (id), orders_user_id_idx (user_id)
- Запрос: SELECT u.email, COUNT(o.id) FROM users u JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2026-01-01' GROUP BY u.email ORDER BY COUNT(o.id) DESC LIMIT 10;
- EXPLAIN (ANALYZE, BUFFERS): [вставьте сюда вывод]
Что нужно:
1. Определи самую дорогую операцию (по actual time и loops).
2. Предложи конкретные индексы с синтаксисом CREATE INDEX CONCURRENTLY.
3. Если нужен рефакторинг запроса — перепиши его.
4. Объясни, почему это поможет, с оценкой ожидаемого ускорения.
5. Предупреди о возможных побочных эффектах (например, рост WAL или замедление INSERT).
Пример использования:
Вы вставляете вывод EXPLAIN, где видно Hash Join с rows=5000000 и Filter: (created_at > '2026-01-01'). Модель отвечает: «Добавьте индекс CREATE INDEX CONCURRENTLY idx_orders_created_at ON orders(created_at) INCLUDE (user_id);. Это позволит использовать Index Only Scan. Ожидаемое ускорение — в 8–10 раз. Побочный эффект: каждый INSERT будет писать в дополнительный индекс, что увеличит нагрузку на запись примерно на 15%».
2. Генерация индексов для сложных аналитических запросов
Задача: Нужно ускорить агрегацию по нескольким колонкам с фильтрацией.
Промт:
Ты — DBA с 10-летним опытом. Для запроса ниже предложи оптимальные индексы (B-tree, GIN, BRIN или составные).
Запрос: SELECT date_trunc('day', created_at) AS day, status, SUM(total) FROM orders WHERE created_at BETWEEN '2026-01-01' AND '2026-09-30' AND status IN ('paid', 'shipped') GROUP BY 1, 2;
Схема таблицы: orders (id bigserial, user_id int, created_at timestamptz, status text, total numeric).
Требования:
- Учти, что таблица партиционирована по created_at (партиции по месяцам).
- Предложи минимум два варианта: для OLTP-нагрузки (частые INSERT) и для OLAP (редкие INSERT, быстрые SELECT).
- Для каждого варианта напиши DDL и объясни trade-off.
- Укажи, нужно ли обновлять статистику (ANALYZE) после создания.
Пример: Модель предложит для OLAP составной индекс (status, created_at) INCLUDE (total) и BRIN-индекс по created_at для больших партиций. Для OLTP — только (created_at, status), чтобы не раздувать WAL.
3. Переписывание запроса с подзапросами на JOIN
Задача: Запрос с коррелированными подзапросами работает медленно.
Промт:
Перепиши SQL-запрос, заменив коррелированные подзапросы на JOIN или оконные функции. Сохрани логику.
Исходный запрос:
SELECT u.id, u.email, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_count, (SELECT MAX(created_at) FROM orders o WHERE o.user_id = u.id) AS last_order FROM users u WHERE u.created_at > '2025-01-01';
Версия PostgreSQL: 17.
Что нужно:
1. Дай переписанный вариант.
2. Сравни планы выполнения: покажи, какие операции исчезнут (например, SubPlan).
3. Оцени, при каком размере таблиц выигрыш будет максимальным.
4. Если есть альтернатива через LATERAL — предложи и её.
Пример: Модель выдаст вариант с LEFT JOIN LATERAL или с GROUP BY + JOIN. В ответе будет: «Исходный запрос выполняет N+1 подзапросов. Новый вариант делает один проход по orders с хеш-агрегацией. На 1 млн пользователей ускорение может быть в 20–50 раз».
4. Миграция схемы PostgreSQL без блокировки таблиц
Задача: Добавить колонку с значением по умолчанию в таблицу на 100 млн строк, не останавливая запись.
Промт:
Ты — эксперт по zero-downtime миграциям в PostgreSQL. Нужно добавить колонку `discount numeric DEFAULT 0 NOT NULL` в таблицу orders (100 млн строк).
Требования:
- Никаких блокировок более 1 секунды.
- Использовать только встроенные средства PostgreSQL (без gh-ost и pg_repack).
- Пошаговый план с командами.
- Учесть версию PostgreSQL 17 (в ней есть улучшения для ADD COLUMN с DEFAULT).
Дай:
1. Последовательность SQL-команд.
2. Объясни, почему каждая команда безопасна.
3. Что делать, если нужно откатить миграцию.
Пример: Модель ответит: «В PostgreSQL 11+ ADD COLUMN ... DEFAULT не перезаписывает таблицу, а хранит значение по умолчанию в каталоге. Команда: ALTER TABLE orders ADD COLUMN discount numeric DEFAULT 0 NOT NULL; — выполнится мгновенно. Для отката: ALTER TABLE orders DROP COLUMN discount;. Если нужно изменить тип — используйте ALTER TABLE ... ALTER COLUMN ... TYPE ... USING ... с предварительным созданием новой колонки и триггером».
5. Оптимизация MongoDB: анализ explain() и выбор индекса
Задача: Запрос в MongoDB выполняется 3 секунды, коллекция 10 млн документов.
Промт:
Ты — сертифицированный MongoDB DBA (версия 8.0). Проанализируй вывод explain('executionStats') и предложи индекс.
Коллекция: users. Документ: { _id, email, profile: { age, city }, created_at, last_login }.
Запрос: db.users.find({ 'profile.city': 'Moscow', 'profile.age': { $gte: 25 } }).sort({ last_login: -1 }).limit(20);
Вывод explain: [вставьте JSON]
Что нужно:
1. Определи, используется ли COLLSCAN или IXSCAN.
2. Предложи составной индекс с правильным порядком полей (ESR-правило: Equality, Sort, Range).
3. Напиши команду createIndex.
4. Проверь, не будет ли индекс слишком большим (оцени размер).
5. Предложи, как проверить эффективность после создания.
Пример: Модель скажет: «Порядок полей: { 'profile.city': 1, last_login: -1, 'profile.age': 1 }. Это соответствует ESR: city — equality, last_login — sort, age — range. Создайте индекс: db.users.createIndex({ 'profile.city': 1, last_login: -1, 'profile.age': 1 }). Ожидаемое ускорение — с 3 с до 50 мс».
6. Генерация миграции для MongoDB без простоя
Задача: Переименовать поле user_name в username во всех документах, не останавливая приложение.
Промт:
Ты — эксперт по миграциям MongoDB. Нужно переименовать поле `user_name` в `username` в коллекции users (5 млн документов). Приложение продолжает работать и пишет в оба поля.
Требования:
- Миграция должна идти батчами по 1000 документов.
- Не блокировать коллекцию.
- Предусмотреть возможность отката.
- Написать скрипт на Node.js (mongosh) с использованием bulkWrite.
Дай:
1. Пошаговый план: сначала добавить новое поле, потом переключить чтение, потом удалить старое.
2. Код скрипта с прогрессом.
3. Как проверить, что все документы мигрированы.
Пример: Модель предложит использовать $rename в цикле с limit(1000), но предупредит: $rename блокирует документ. Лучше сделать updateMany с $set: { username: '$user_name' }, затем после проверки — $unset: { user_name: '' }. Скрипт будет выводить количество обработанных документов.
7. Автоматическое создание партиций для PostgreSQL
Задача: Настроить автоматическое создание партиций по месяцам.
Промт:
Ты — администратор PostgreSQL 17. Напиши SQL-функцию и триггер для автоматического создания партиции на следующий месяц для таблицы orders, партиционированной по RANGE (created_at).
Требования:
- Функция должна проверять, существует ли партиция.
- Имя партиции: orders_YYYY_MM.
- Использовать pg_partman или встроенные средства? Объясни выбор.
- Если встроенные — напиши код на PL/pgSQL.
- Предусмотреть логирование ошибок.
Пример: Модель предложит решение на PL/pgSQL: функция create_next_month_partition() с динамическим SQL EXECUTE format('CREATE TABLE orders_%s PARTITION OF orders FOR VALUES FROM (%L) TO (%L)', ...). Также покажет, как повесить вызов на cron через pg_cron.
8. Перевод запроса с MySQL на PostgreSQL
Задача: Мигрировать сложный запрос с MySQL 8.0 на PostgreSQL 17.
Промт:
Переведи запрос с MySQL на PostgreSQL. Учти различия в синтаксисе и функциях.
MySQL запрос:
SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, GROUP_CONCAT(DISTINCT status) AS statuses FROM orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 6 MONTH) GROUP BY month;
Требования:
- Сохрани логику.
- Замени функции на аналогичные в PostgreSQL.
- Если есть различия в поведении (например, GROUP_CONCAT vs STRING_AGG) — объясни.
- Предложи, как оптимизировать под PostgreSQL (индексы, настройки).
Пример: Модель выдаст: SELECT to_char(created_at, 'YYYY-MM') AS month, STRING_AGG(DISTINCT status, ',') AS statuses FROM orders WHERE created_at >= NOW() - INTERVAL '6 months' GROUP BY 1;. Пояснит, что STRING_AGG требует явного разделителя, и предложит индекс по created_at.
9. Оптимизация соединений (JOIN) в MongoDB через $lookup
Задача: Заменить множественные запросы к связанным коллекциям на один агрегационный пайплайн.
Промт:
Ты — эксперт по агрегациям MongoDB. У меня есть две коллекции: orders (user_id, total, created_at) и users (_id, email, city). Нужно получить для каждого пользователя сумму заказов за последний месяц.
Текущая реализация: сначала find по users, потом для каждого user — find по orders (N+1).
Требования:
- Перепиши на один агрегационный пайплайн с $lookup.
- Учти, что orders может быть 10 млн, users — 1 млн.
- Предложи индексы для $lookup.
- Оцени производительность и сравни с N+1.
Пример: Модель предложит пайплайн: db.users.aggregate([{ $lookup: { from: 'orders', let: { userId: '$_id' }, pipeline: [{ $match: { $expr: { $eq: ['$user_id', '$$userId'] }, created_at: { $gte: new Date(Date.now() - 30*24*60*60*1000) } } }, { $group: { _id: null, total: { $sum: '$total' } } }], as: 'monthly' } }]). Укажет, что для $lookup нужен индекс по orders.user_id.
10. Поиск и устранение deadlock в PostgreSQL
Задача: Приложение периодически ловит ошибку deadlock detected.
Промт:
Ты — эксперт по конкурентности в PostgreSQL. В логах ошибка: deadlock detected. Вот два запроса, которые выполняются параллельно:
Транзакция A: UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2;
Транзакция B: UPDATE accounts SET balance = balance - 50 WHERE id = 2; UPDATE accounts SET balance = balance + 50 WHERE id = 1;
Что нужно:
1. Объясни причину deadlock.
2. Предложи способы предотвращения: сортировка блокировок, таймауты, advisory locks.
3. Напиши исправленный код для обеих транзакций.
4. Как настроить параметры PostgreSQL (deadlock_timeout, lock_timeout) для минимизации.
Пример: Модель объяснит, что транзакции захватывают строки в разном порядке. Решение: всегда обновлять строки в порядке возрастания id. Исправленный код: в транзакции A сначала id=1, потом id=2; в B — тоже сначала id=1, потом id=2. Дополнительно можно установить lock_timeout = '5s'.
11. Генерация тестовых данных для нагрузочного тестирования
Задача: Нужно создать 1 млн реалистичных записей в PostgreSQL для теста производительности.
Промт:
Напиши SQL-скрипт для генерации 1 000 000 строк в таблицу orders (id, user_id, created_at, total, status).
Требования:
- Использовать generate_series.
- created_at — случайная дата за последний год.
- total — случайное число от 10 до 10000.
- status — случайный из ('paid', 'shipped', 'cancelled').
- Скрипт должен выполняться быстро (не более 30 секунд).
- Предложи, как вставить данные пачками, чтобы не переполнить WAL.
Пример: Модель выдаст:
INSERT INTO orders (user_id, created_at, total, status)
SELECT (random()*100000)::int, NOW() - (random() * INTERVAL '365 days'), (random()*9990+10)::numeric(10,2), (ARRAY['paid','shipped','cancelled'])[floor(random()*3+1)]
FROM generate_series(1, 1000000);
Или предложит использовать COPY для ускорения.
12. Мониторинг и алертинг для PostgreSQL и MongoDB
Задача: Настроить сбор метрик и алерты на медленные запросы.
Промт:
Ты — SRE. Предложи набор промтов для настройки мониторинга PostgreSQL 17 и MongoDB 8.0.
Что нужно:
1. Какие метрики собирать (pg_stat_statements, pg_stat_activity, MongoDB serverStatus).
2. Как настроить алерты на запросы дольше 1 секунды.
3. Напиши пример конфигурации для Prometheus + Grafana или для встроенных средств.
4. Как использовать pg_stat_statements для поиска топ-10 медленных запросов.
5. Для MongoDB — как включить profiler и анализировать slowms.
Пример: Модель предложит включить pg_stat_statements через shared_preload_libraries, затем запрос: SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;. Для MongoDB — db.setProfilingLevel(1, { slowms: 100 }) и анализ system.profile.
Все 12 промтов работают в паре с любой современной LLM: GPT-4, Claude, Gemini, YandexGPT. Главное — не ленитесь подставлять реальные планы запросов и схемы. Чем больше контекста, тем точнее ответ. И помните: ИИ не заменяет DBA, но снимает рутину, позволяя сосредоточиться на архитектуре.
Попробуйте прямо сейчас: возьмите свой самый медленный запрос, скопируйте промт №1 и вставьте EXPLAIN. Результат может удивить. А если хотите системно прокачать навыки работы с базами и ИИ — изучите наши текстовые курсы на asibiont.com. Там нет воды, только практика.
Комментарии