Вы когда-нибудь смотрели на EXPLAIN ANALYZE и чувствовали, что смотрите в глаза бездны? Я — да. После того как мой запрос на 10 миллионов строк превратился в 15-секундную пытку для продакшена, я понял: пора менять подход. Я перепробовал десятки инструментов, но самым недооценённым оказались… промты для нейросетей. Да, те самые, что пишут стихи и рисуют котиков, — при правильной формулировке они могут стать вашим персональным DBA-консультантом. В этой статье я собрал 12 проверенных промтов, которые помогут вам анализировать запросы, проектировать схемы и наводить порядок в индексах — от простых подсказок до глубокого реверс-инжиниринга. Поехали.
Базовый уровень: учим нейросеть думать как оптимизатор
1. EXPLAIN, но по-человечески
Задача: Превратить сухой вывод EXPLAIN в понятный диагноз.
Промт: «Ты — эксперт по PostgreSQL. Объясни, что происходит в этом плане запроса, как если бы я был разработчиком с 5-летним опытом, но не DBA. Укажи узкие места, почему они возникли и что можно улучшить. План: [вставьте вывод EXPLAIN]»
Пример результата: Нейросеть выделит Seq Scan на таблице orders как проблему, объяснит, что из-за отсутствия индекса на customer_id при WHERE customer_id = 123 СУБД сканирует все строки, и порекомендует CREATE INDEX idx_orders_customer_id ON orders(customer_id);. Это экономит часы чтения документации.
2. SQL-ревью без боли
Задача: Проверить запрос на скрытые ошибки и неоптимальности.
Промт: «Проведи код-ревью SQL-запроса для PostgreSQL. Найди потенциальные проблемы: неиспользуемые индексы, лишние JOIN, неявные приведения типов, риск декартовых произведений. Предложи исправления. Запрос: [вставьте SQL]»
Пример: Для запроса с JOIN по VARCHAR и INTEGER полям нейросеть заметит неявное приведение, которое убивает индексацию, и предложит явный CAST или изменение типа колонки.
3. Мастер-класс по индексам
Задача: Сгенерировать оптимальный набор индексов для таблицы.
Промт: «Предложи набор индексов для таблицы users (id, email, last_login, created_at). Учти частые запросы: поиск по email, сортировка по created_at, фильтрация по last_login. Объясни, почему каждый индекс нужен, и укажи, какие могут быть избыточными»
Пример: Нейросеть порекомендует уникальный индекс на email, составной индекс на (last_login, created_at) для запросов с фильтром и сортировкой, но предупредит, что индекс на created_at отдельно избыточен, если есть составной.
Продвинутый уровень: когда нужно копать глубже
4. Диагноз по логам медленных запросов
Задача: Проанализировать лог медленных запросов и найти паттерны.
Промт: «Вот фрагмент лога медленных запросов PostgreSQL (формат csvlog). Сгруппируй их по типу проблемы: отсутствие индексов, неоптимальные JOIN, слишком большие выборки. Для каждой группы дай рекомендацию. Лог: [вставьте строки]»
Пример: Нейросеть заметит, что 80% медленных запросов используют LIKE '%text%', и предложит перейти на полнотекстовый поиск (GIN-индекс, tsvector).
5. Реверс-инжиниринг схемы
Задача: Восстановить структуру БД по набору запросов.
Промт: «По этим SQL-запросам восстанови вероятную схему базы данных: таблицы, колонки, связи, индексы. Укажи, какие поля, скорее всего, являются внешними ключами. Запросы: [вставьте]»
Пример: Из трёх запросов с JOIN по customer_id нейросеть выведет схему с таблицами customers, orders, products и связью многие-ко-многим через order_items.
6. Миграции без страха
Задача: Сгенерировать безопасные SQL-миграции для изменения схемы.
Промт: «Напиши SQL-миграцию для PostgreSQL: добавить колонку status в таблицу orders с типом VARCHAR(20) и значением по умолчанию 'pending', затем создать индекс на status. Миграция должна быть идемпотентной (безопасной при повторном запуске). Используй DO $$ ... $$ блоки или IF NOT EXISTS»
Пример: Нейросеть выдаст ALTER TABLE orders ADD COLUMN IF NOT EXISTS status VARCHAR(20) DEFAULT 'pending'; CREATE INDEX IF NOT EXISTS idx_orders_status ON orders(status);, что позволяет многократно применять миграцию без ошибок.
7. Профилирование Mongo: как ускорить агрегации
Задача: Оптимизировать агрегационный пайплайн MongoDB.
Промт: «Вот агрегационный пайплайн MongoDB. Проанализируй его производительность: какие стадии ($match, $lookup, $group) можно оптимизировать, какие индексы нужны. Предложи улучшенную версию. Пайплайн: [вставьте]»
Пример: Нейросеть посоветует переместить $match в начало пайплайна, чтобы уменьшить количество документов на входе $lookup, и предложит создать составной индекс на поля, используемые в $match и $sort.
Экспертный уровень: тонкости и нестандартные решения
8. План запроса: выжимаем максимум
Задача: Глубокая оптимизация сложного запроса с подзапросами и CTE.
Промт: «Вот сложный запрос с CTE и оконными функциями. Проанализируй его план выполнения и предложи альтернативную структуру: возможно, заменить CTE на подзапросы, добавить материализованные представления или изменить порядок соединений. Приведи примеры с EXPLAIN. Запрос: [вставьте]»
Пример: Нейросеть заметит, что CTE материализуются каждый раз, и предложит использовать WITH ... AS MATERIALIZED или наоборот, NOT MATERIALIZED, если это уменьшит число сканирований, что даст прирост до 2 раз.
9. Партиционирование: грамотный подход
Задача: Спроектировать партиционирование для большой таблицы.
Промт: «Таблица events содержит 1 миллиард строк и быстро растёт. Предложи стратегию партиционирования в PostgreSQL: по диапазону дат, списку или хэшу. Опиши, как создать партиции, как управлять ими и какие индексы использовать»
Пример: Нейросеть порекомендует партиционирование по created_at с месячными интервалами, подскажет использовать PARTITION BY RANGE (created_at) и регулярно создавать новые партиции через CREATE TABLE ... PARTITION OF.
10. Мониторинг и алерты через промт
Задача: Настроить систему мониторинга на основе метрик БД.
Промт: «Составь SQL-запросы для мониторинга PostgreSQL: количество активных соединений, размер таблиц, число мёртвых кортежей, время выполнения запросов. Объясни, как интерпретировать результаты и какие пороговые значения считать критическими»
Пример: Нейросеть выдаст запросы к pg_stat_activity, pg_stat_user_tables и pg_stat_statements, а также объяснит, что значение n_dead_tup выше 20% от n_live_tup — сигнал к VACUUM.
11. Шардирование и репликация: сохраняем консистентность
Задача: Спроектировать архитектуру шардирования для MySQL.
Промт: «Спроектируй схему шардирования для MySQL: как выбрать ключ шардирования, как организовать репликацию, как обеспечить глобальную уникальность ID (например, через UUID или снежинки). Опиши плюсы и минусы подхода»
Пример: Нейросеть предложит шардировать по user_id с использованием LAST_INSERT_ID() в транзакциях, но предупредит о проблемах с JOIN между шардами и порекомендует использовать агрегацию на уровне приложения.
12. Анализ утечки памяти в БД
Задача: Выявить причины роста потребления памяти.
Промт: «У PostgreSQL растёт потребление памяти. Проанализируй возможные причины: утечки в коде, настройки shared_buffers, work_mem, утечки через подготовленные statements. Предложи диагностические запросы и способы решения»
Пример: Нейросеть посоветует проверить pg_prepared_statements, pg_stat_activity и pg_settings, а также уменьшить work_mem для параллельных запросов, если они вызывают своппинг.
Выводы
Эти 12 промтов — не серебряная пуля, но они превращают LLM в полноценного консультанта по базам данных, который доступен 24/7. Я перестал тратить часы на чтение документации — теперь я трачу минуты на формулировку промта и получаю точные, практические советы, подкреплённые примерами. Попробуйте применить их к своим проектам, и вы удивитесь, как быстро ваши запросы станут летать. А если у вас есть свои проверенные промты — делитесь в комментариях, давайте создадим базу знаний вместе!
Комментарии