12 промтов для PostgreSQL, MongoDB и Redis: от EXPLAIN до шардирования и кэша

12 промтов для PostgreSQL, MongoDB и Redis: от EXPLAIN до шардирования и кэша

Медленный JOIN, неожиданный seq scan, N+1 в ORM, миграция, которая блокирует таблицу на минуты, или кэш, который внезапно стал узким местом — знакомо? В 2026 году LLM перестали быть игрушкой для генерации «Hello, World». Они превратились в полноценного DBA-напарника, который читает EXPLAIN ANALYZE, находит проблемные места в схеме и предлагает готовые решения. Но есть нюанс: без точного промта вы получите общие советы вроде «добавьте индекс». С точным — пошаговый план с командами, который можно применить в проде через 10 минут.

Эта подборка — 12 сценариев, которые я собрал из реальной практики работы с PostgreSQL, MongoDB и Redis. Для каждого промта — пример входных данных (план запроса, схема, лог) и что делать с ответом модели. Все команды и синтаксис проверены на актуальных версиях: PostgreSQL 16, MongoDB 7.0, Redis 7.2. Ссылки на официальную документацию прилагаются.

1. Расшифровка EXPLAIN ANALYZE для PostgreSQL

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

Промт:

Ты — эксперт по PostgreSQL 16. Ниже — вывод EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) для запроса. 
1. Найди узкие места: seq scan на больших таблицах, nested loop с большим числом итераций, sort/hash, ушедшие в disk.
2. Объясни каждый узел простыми словами.
3. Предложи конкретные действия: какие индексы создать (с точным CREATE INDEX), какие настройки изменить (work_mem, random_page_cost), как переписать запрос.
4. Дай ожидаемый эффект в терминах «уменьшение стоимости» и «устранение disk spill».

План:
<вставьте JSON из EXPLAIN>

Пример входных данных:

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT o.id, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > now() - interval '7 days';

Что делать с ответом: Проверьте рекомендации по индексам через EXPLAIN ещё раз. Если модель предлагает CREATE INDEX CONCURRENTLY — используйте его в проде, чтобы избежать блокировок (PostgreSQL docs: CREATE INDEX).

2. Поиск N+1 запросов в ORM

Задача: Приложение делает сотни мелких запросов вместо одного JOIN.

Промт:

Проанализируй код ниже (Django/SQLAlchemy/Prisma). Найди паттерн N+1: обращения к связанным объектам в цикле.
Предложи исправление: select_related/prefetch_related (Django), joinedload/selectinload (SQLAlchemy), include (Prisma).
Покажи до/после и объясни, почему это устраняет N+1.

Код:
<вставьте код>

Пример: В Django for order in Order.objects.all(): print(order.customer.name) даёт N+1. Решение — Order.objects.select_related('customer'). Официальная документация: Django select_related.

Что делать: Замените в коде и проверьте через Django Debug Toolbar или django.db.connection.queries.

3. Генерация индексов под конкретный запрос

Промт:

Для запроса ниже предложи оптимальные индексы в PostgreSQL 16.
Учти: селективность, порядок колонок, покрывающие индексы (INCLUDE), частичные индексы (WHERE), выражение-индексы.
Дай точный DDL и объясни, почему выбран такой порядок колонок.

Запрос:
<SQL>
Схема таблицы:
<\d+ table>

Пример: Для WHERE status = 'active' AND created_at > '2026-01-01' ORDER BY created_at DESC подойдёт CREATE INDEX CONCURRENTLY idx_orders_active_created ON orders (created_at DESC) WHERE status = 'active';.

Что делать: Проверьте через EXPLAIN — должен появиться Index Scan вместо Seq Scan. Помните: каждый индекс замедляет INSERT/UPDATE.

4. Рефакторинг медленных JOIN

Промт:

Перепиши запрос ниже, чтобы ускорить JOIN.
Варианты: замена JOIN на EXISTS, LATERAL, CTE с MATERIALIZED, предварительная агрегация в подзапросе.
Для каждого варианта дай SQL и объясни, когда он выигрывает.

Запрос:
<SQL>
План:
<EXPLAIN>

Пример: Вместо JOIN (SELECT ... GROUP BY ...) часто быстрее LATERAL или EXISTS, если нужна только проверка наличия. Документация: PostgreSQL LATERAL.

5. Схемы шардирования в MongoDB

Промт:

Спроектируй стратегию шардирования для коллекции в MongoDB 7.0.
Дано: объём данных, паттерны запросов, распределение по регионам.
Предложи shard key (hashed или ranged), обоснуй выбор, покажи команды sh.shardCollection.
Учти: hotspotting, jumbo chunks, балансировку.

Данные:
<описание>

Пример команды: sh.shardCollection("db.orders", { customer_id: "hashed" }). Документация: MongoDB Sharding.

Что делать: Проверьте распределение через db.collection.getShardDistribution().

6. Стратегии кэширования в Redis

Промт:

Предложи стратегию кэширования в Redis 7.2 для сценария ниже.
Варианты: cache-aside, write-through, write-behind, read-through.
Укажи TTL, политику инвалидации, структуры данных (String, Hash, Sorted Set), защиту от cache stampede (lock, probabilistic early expiration).
Покажи примеры команд.

Сценарий:
<описание>

Пример: Для счётчиков просмотров — INCR, для рейтингов — ZADD/ZRANGE. Документация: Redis commands.

7. Безопасные миграции без простоя

Промт:

Сгенерируй план миграции в PostgreSQL без блокировки таблицы.
Используй: ADD COLUMN с DEFAULT NULL, CREATE INDEX CONCURRENTLY, ALTER TABLE ... SET NOT NULL после backfill, батчинг.
Дай SQL и порядок шагов. Укажи, что нельзя делать в транзакции.

Миграция:
<описание>

Пример: ALTER TABLE users ADD COLUMN phone text; затем backfill батчами, затем ALTER TABLE users ALTER COLUMN phone SET NOT NULL;. Документация: PostgreSQL ALTER TABLE.

8. Разбор инцидента по логам

Промт:

Проанализируй фрагмент логов PostgreSQL/MongoDB/Redis ниже.
Найди: ошибки, deadlock, timeout, OOM, медленные запросы.
Предложи root cause и шаги для устранения.

Логи:
<вставьте логи>

Пример: deadlock detected в PostgreSQL — ищите порядок блокировок в приложении. Документация: PostgreSQL Logging.

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

Промт:

Перепиши aggregation pipeline ниже для ускорения.
Используй: $match в начале, $project для уменьшения полей, $lookup с pipeline, индексы.
Дай новый pipeline и объясни выигрыш.

Pipeline:
<код>

Пример: Перенесите $match перед $group, чтобы уменьшить объём. Документация: MongoDB Aggregation.

10. Настройка TTL и eviction в Redis

Промт:

Настрой Redis 7.2 для сценария: <описание>.
Предложи maxmemory, maxmemory-policy (allkeys-lru, volatile-lru и т.д.), TTL для ключей.
Объясни, почему выбранная политика не приведёт к потере критичных данных.

Пример: maxmemory-policy allkeys-lru для кэша, volatile-lru если есть персистентные ключи. Документация: Redis eviction.

11. Репликация и отказоустойчивость

Промт:

Спроектируй схему репликации для <PostgreSQL/MongoDB/Redis>.
Укажи: sync/async, количество реплик, failover, read preference.
Дай конфиги и команды проверки.

Пример: PostgreSQL streaming replication: primary_conninfo в postgresql.conf. Документация: PostgreSQL Replication.

12. Мониторинг и алерты

Промт:

Предложи набор метрик и алертов для <БД>.
Используй: pg_stat_statements, MongoDB Atlas metrics, Redis INFO.
Укажи пороги и что делать при срабатывании.

Пример: pg_stat_statements для топ-10 медленных запросов. Документация: pg_stat_statements.

Эти 12 промтов — не серебряная пуля, а ускоритель. LLM не заменит DBA, но снимет рутину: расшифровку планов, поиск N+1, генерацию DDL. Главное — всегда проверяйте рекомендации на тестовом стенде. Начните с одного сценария, например, EXPLAIN ANALYZE, и вы удивитесь, сколько времени освободится. А если хотите системно прокачать навыки работы с базами данных и AI-инструментами — загляните на asibiont.com: там есть практические курсы по SQL, NoSQL и промпт-инжинирингу.