PostgreSQL под капотом: как превратить LLM в персонального DBA и не спалить прод

Когда я впервые попросил нейросеть объяснить, почему мой запрос к PostgreSQL работает 20 секунд вместо 20 миллисекунд, она выдала ответ, который можно было упаковать в мем про «просто добавь индекс». Но после пары месяцев экспериментов я понял: LLM — это не замена DBA, а мощный ассистент, который экономит часы на рутине. В этой статье я собрал 14 промтов, которые реально помогают мне в работе с PostgreSQL: от диагностики медленных запросов до безопасных миграций. Каждый промт снабжен примером и пояснением, как его адаптировать под свою задачу.

Базовые промты: для тех, кто хочет ускорить работу с PostgreSQL

Промт 1. Диагностика медленных запросов

Задача: Найти причину медленного выполнения запроса.

Промт:

У меня есть запрос к PostgreSQL, который выполняется 5 секунд. Вот его план выполнения:
[вставьте EXPLAIN ANALYZE]

Проанализируй план и укажи:
1. Какие операции самые дорогие?
2. Где узкие места?
3. Какие индексы могли бы ускорить запрос?
4. Есть ли проблемы с оценкой количества строк?
Ответ дай в виде структурированного отчета.

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

Анализ:
- Seq Scan на таблице orders (стоимость 1000, строк 50000) — главный тормоз.
- Hash Join между orders и users работает нормально, но требует 256MB памяти.
- Оценка строк совпадает с фактической, но фильтр по дате не использует индекс.

Рекомендации:
- Создайте индекс: CREATE INDEX idx_orders_created_at ON orders (created_at);
- Включите enable_seqscan = off для теста, но лучше просто добавьте индекс.

Пояснение: Этот промт превращает LLM в анализатора планов запросов. Главное — дать ей реальный EXPLAIN ANALYZE, а не пересказ. Чем больше контекста, тем точнее совет.

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

Задача: Сгенерировать индексы для существующей таблицы.

Промт:

У меня таблица users с полями id, email, created_at, last_login. Запросы: поиск по email, сортировка по created_at, фильтр по last_login > дата. Какие индексы создать?

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

CREATE UNIQUE INDEX idx_users_email ON users (email);
CREATE INDEX idx_users_created_at ON users (created_at);
CREATE INDEX idx_users_last_login ON users (last_login);

Пояснение: Этот промт полезен на этапе проектирования. Но не забывайте: индексы замедляют запись, поэтому LLM должна учесть соотношение чтения и записи. Уточните это в промте.

Промт 3. Оптимизация запросов без изменения схемы

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

Промт:

Вот медленный запрос:
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE created_at > '2025-01-01');
Он выполняется 3 секунды. Перепиши его оптимальнее.

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

SELECT o.* FROM orders o JOIN users u ON o.user_id = u.id WHERE u.created_at > '2025-01-01';

Пояснение: LLM часто предлагает заменить IN на JOIN или наоборот. Но важно проверить эквивалентность результатов. Я всегда прошу объяснить, почему новый запрос быстрее.

Продвинутые промты: для тех, кто хочет глубже понять PostgreSQL

Промт 4. Анализ узких мест с помощью pg_stat_statements

Задача: Найти самые частые и медленные запросы на сервере.

Промт:

Вот вывод из pg_stat_statements для моей базы (топ-10 по total_time):
[вставьте вывод]

Проанализируй, какие запросы стоит оптимизировать в первую очередь, и предложи конкретные меры.

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

Запрос #3 (UPDATE на таблицу inventory) занимает 40% времени. Причина — блокировки из-за конкуренции. Рекомендую:
- Добавить индекс на внешний ключ product_id.
- Рассмотреть партиционирование таблицы по дате.
- Изменить уровень изоляции на READ COMMITTED.

Пояснение: Этот промт требует, чтобы вы сами собрали статистику. LLM не подключена к вашей БД, но она отлично интерпретирует цифры.

Промт 5. Проектирование схемы данных с учетом нормализации

Задача: Спроектировать таблицы для блога.

Промт:

Спроектируй схему для блога: пользователи, посты, комментарии, теги. Учти требования: посты могут иметь много тегов, комментарии привязаны к постам и пользователям. Покажи SQL-код.

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

CREATE TABLE users (id SERIAL PRIMARY KEY, username TEXT UNIQUE, email TEXT UNIQUE);
CREATE TABLE posts (id SERIAL PRIMARY KEY, user_id INTEGER REFERENCES users(id), title TEXT, content TEXT, created_at TIMESTAMP DEFAULT now());
CREATE TABLE tags (id SERIAL PRIMARY KEY, name TEXT UNIQUE);
CREATE TABLE post_tags (post_id INTEGER REFERENCES posts(id), tag_id INTEGER REFERENCES tags(id), PRIMARY KEY (post_id, tag_id));
CREATE TABLE comments (id SERIAL PRIMARY KEY, post_id INTEGER REFERENCES posts(id), user_id INTEGER REFERENCES users(id), body TEXT, created_at TIMESTAMP DEFAULT now());

Пояснение: LLM хорошо справляется с базовыми схемами. Но обязательно укажите ограничения: например, длину текста, индексы для полнотекстового поиска.

Промт 6. Оптимизация запросов с помощью EXPLAIN ANALYZE

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

Промт:

Вот план выполнения:
[вставьте EXPLAIN ANALYZE]

Объясни, что означает каждая строка, и где проблема. Предложи, как исправить.

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

Строка 1: Seq Scan on products (cost=0.00..100.00, rows=1000) — полное сканирование, потому что нет индекса.
Строка 2: Filter: (price > 100) — фильтр применяется после сканирования, что неэффективно.
Решение: создать индекс на price.

Пояснение: Этот промт — база для обучения. LLM может объяснить непонятные термины, что особенно полезно новичкам.

Экспертные промты: для тех, кто готов к сложным задачам

Промт 7. Безопасные миграции с нулевым даунтаймом

Задача: Провести миграцию таблицы без остановки сервиса.

Промт:

Мне нужно изменить тип колонки id с INTEGER на BIGINT в таблице orders. Как сделать это без даунтайма?

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

-- Шаг 1: Добавить новую колонку
ALTER TABLE orders ADD COLUMN id_new BIGINT;
-- Шаг 2: Заполнить её
UPDATE orders SET id_new = id;
-- Шаг 3: Создать индекс и ограничения
ALTER TABLE orders ALTER COLUMN id_new SET NOT NULL;
-- Шаг 4: Переключить колонку
ALTER TABLE orders DROP COLUMN id CASCADE;
ALTER TABLE orders RENAME COLUMN id_new TO id;

Пояснение: LLM предложит поэтапный план, но не забудьте про блокировки и триггеры. В реальности лучше использовать pg_repack или сторонние инструменты.

Промт 8. Оптимизация с помощью партиционирования

Задача: Разбить большую таблицу на партиции.

Промт:

У меня таблица logs с 100 млн строк. Планирую партиционировать по дате. Составь скрипт для создания партиций на месяц.

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

CREATE TABLE logs (id BIGSERIAL, created_at DATE, message TEXT) PARTITION BY RANGE (created_at);
CREATE TABLE logs_2026_08 PARTITION OF logs FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');
CREATE INDEX idx_logs_created_at ON logs (created_at);

Пояснение: Убедитесь, что LLM знает, что партиционирование требует уникальных индексов, включающих ключ партиционирования.

Промт 9. Настройка параметров конфигурации

Задача: Подобрать параметры PostgreSQL для конкретного железа.

Промт:

У меня сервер с 16 CPU и 64GB RAM. PostgreSQL 16. Дай рекомендуемые значения для shared_buffers, work_mem, effective_cache_size.

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

shared_buffers = 16GB (25% от RAM)
work_mem = 256MB (для сортировок)
effective_cache_size = 48GB (75% от RAM)

Пояснение: LLM может дать общие рекомендации, но всегда сверяйтесь с официальной документацией. Параметры зависят от нагрузки.

Промт 10. Анализ блокировок и взаимоблокировок

Задача: Найти причину блокировок.

Промт:

Вот вывод pg_locks для моей системы:
[вставьте вывод]

Определи, какие транзакции блокируют друг друга, и предложи способы решения.

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

Транзакция A держит ShareLock на таблицу orders, транзакция B хочет ExclusiveLock. Это приводит к ожиданию. Рекомендую:
- Уменьшить время транзакций.
- Использовать SELECT ... FOR UPDATE SKIP LOCKED.

Пояснение: Этот промт требует понимания типов блокировок. LLM может объяснить, но решение часто требует ручного вмешательства.

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

Задача: Настроить потоковую репликацию.

Промт:

Опиши шаги для настройки потоковой репликации PostgreSQL 16 с двумя серверами.

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

На основном сервере:
- Установите listen_addresses = '*'
- Установите wal_level = replica
- Создайте пользователя для репликации: CREATE USER replica REPLICATION LOGIN PASSWORD 'secret';
- Настройте pg_hba.conf для разрешения подключений.
На резервном сервере:
- Выполните pg_basebackup -h primary -D /var/lib/postgresql/data -U replica
- Создайте файл standby.signal
- Настройте primary_conninfo.

Пояснение: LLM даст общий план, но важно проверить совместимость версий и настройки сети.

Промт 12. Импорт и экспорт данных с оптимизацией

Задача: Быстро импортировать CSV в PostgreSQL.

Промт:

Как импортировать файл CSV размером 10GB в таблицу users с максимальной скоростью?

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

COPY users FROM '/path/to/file.csv' WITH (FORMAT csv, HEADER true);
-- Для ускорения: отключите индексы на время импорта, увеличьте maintenance_work_mem.

Пояснение: Промт хорош для получения советов по оптимизации, но не забывайте о целостности данных.

Промт 13. Объяснение сложных концепций

Задача: Понять MVCC.

Промт:

Объясни, как работает MVCC в PostgreSQL, простыми словами, с примером.

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

MVCC (Multiversion Concurrency Control) позволяет читателям не блокировать писателей. Каждая транзакция видит снимок данных на момент начала. Например, если одна транзакция обновляет строку, другая всё ещё видит старую версию. Это достигается хранением нескольких версий строк.

Пояснение: Полезно для обучения команды. LLM отлично объясняет сложные темы.

Промт 14. Генерация тестовых данных

Задача: Создать тестовые данные для таблицы.

Промт:

Сгенерируй SQL, который вставит 1000 тестовых пользователей в таблицу users с полями name, email, created_at.

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

INSERT INTO users (name, email, created_at)
SELECT 'User'

|| g, 'user' || g || '@example.com', now() - (g || ' days')::interval
FROM generate_series(1, 1000) AS g;

Пояснение: Этот промт экономит время на рутинной генерации данных. Но проверяйте уникальность и типы данных.

Как я использую эти промты на практике

Мой рабочий процесс выглядит так: я собираю реальные данные (EXPLAIN, pg_stat_statements, конфиги), вставляю их в промт и получаю конкретные рекомендации. Затем всегда проверяю на тестовой базе. Ошибка, которую я совершал, — слепое доверие советам LLM. Например, она предложила индекс, который замедлил запись на 30%. Поэтому критически важно понимать основы.

Заключение

LLM не заменят опытного DBA, но они отлично справляются с рутиной: анализ планов, генерация индексов, проектирование схем. Главное — давать им точный контекст и проверять результаты. Начните с базовых промтов, и вы увидите, как много времени они экономят. Если у вас есть свои любимые промты для PostgreSQL — делитесь в комментариях!