Вы когда-нибудь ждали 10 секунд, пока выполнится запрос, который должен работать за миллисекунды? Я — да. И каждый раз это вызывает желание бросить всё и пойти вручную перебирать индексы. Но есть способ проще: современные LLM умеют не только писать код, но и анализировать планы запросов, предлагать индексы и даже проектировать схемы. Я собрал 10 проверенных промтов, которые реально экономят часы рутины. Никакой теории — только готовые формулировки, которые можно скопировать и использовать прямо сейчас.
1. Диагност медленных запросов: EXPLAIN ANALYZE под микроскопом
Когда использовать: Вы нашли медленный запрос, но не понимаете, почему он тормозит. Вместо того чтобы вручную разбирать план, скормите его нейросети.
Промт:
Ты — эксперт по оптимизации PostgreSQL. Вот вывод EXPLAIN ANALYZE для моего запроса:
[вставьте сюда вывод]
Проанализируй план: найди узкие места (Seq Scan, высокий cost, большое число строк на этапах). Предложи конкретные исправления: какие индексы создать, как переписать запрос, стоит ли изменить настройки планировщика. Объясни, что означает каждый проблемный узел, простым языком.
Пример использования: Вы запустили EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42 AND status = 'pending'; и получили многострочный вывод с Seq Scan on orders и Filter: ((user_id = 42) AND (status = 'pending'::text)). Промт выдаст: «Создайте индекс на (user_id, status) — это позволит использовать Index Scan вместо Seq Scan, что сократит время с 100 мс до 1 мс». Я использовал его на реальном проекте: запрос, который выполнялся 2 секунды, стал работать за 10 миллисекунд.
2. Создатель индексов: по описанию запроса
Когда использовать: Вы знаете, какие запросы тормозят, но не знаете, какие индексы создать. Промт генерирует готовые команды CREATE INDEX.
Промт:
Для PostgreSQL у меня есть таблица [имя таблицы] с колонками [список]. Вот частые запросы:
1. [запрос 1]
2. [запрос 2]
Предложи набор индексов для ускорения этих запросов. Учти: индексы должны покрывать условия WHERE, ORDER BY и JOIN. Для каждого индекса дай команду CREATE INDEX и объясни, почему он нужен. Также укажи, какие индексы могут быть избыточными.
Пример использования: Вы даете промту свои запросы, а он возвращает: CREATE INDEX idx_orders_user_status ON orders (user_id, status); и пояснение: «Индекс на (user_id, status) покроет оба условия, а отдельный индекс на status не нужен, так как он неселективен». Я применял это для таблицы с миллионами строк, и скорость выборок выросла в 50 раз.
3. Разбор EXPLAIN из MongoDB: план выполнения
Когда использовать: MongoDB возвращает explain() — вывод, который новичку сложно понять. Промт поможет расшифровать его.
Промт:
Вот вывод explain() из MongoDB для моего запроса:
[вставьте вывод]
Расшифруй его: какой план выбран (COLLSCAN, IXSCAN, SORT)? Где узкие места? Предложи конкретные улучшения: какие индексы создать, как изменить структуру документа или запрос. Объясни, что означает winningPlan и rejectedPlans.
Пример использования: Вы видите "stage": "COLLSCAN" — это значит, что MongoDB сканирует всю коллекцию. Промт порекомендует создать индекс на поле, используемое в фильтре, и покажет, как изменится план на IXSCAN. Я часто использую этот промт для быстрой диагностики: он экономит время на чтении документации.
4. Генератор индексов для MongoDB
Когда использовать: Нужно быстро создать индексы для коллекции на основе типичных запросов.
Промт:
У меня коллекция MongoDB [имя] с документами вида [пример документа]. Вот типичные запросы:
[запрос 1], [запрос 2].
Предложи индексы для ускорения. Учитывай: составные индексы должны соответствовать порядку полей в запросах. Дай команды createIndex() и объясни, как они повлияют на производительность.
Пример использования: Вы передаете промту запросы с фильтрами по userId и createdAt, и получаете: db.orders.createIndex({ userId: 1, createdAt: -1 }) — это ускорит сортировку по дате в пределах пользователя. Я применял это для аналитических выборок, и время ответа сократилось с 3 секунд до 200 миллисекунд.
5. Архитектор схемы: нормализация для PostgreSQL
Когда использовать: Вы проектируете новую таблицу или понимаете, что текущая схема плоская и тормозит. Промт поможет нормализовать или денормализовать её.
Промт:
Вот текущая схема таблицы PostgreSQL: [описание]. Мне нужно [нормализовать/денормализовать] её для повышения производительности. Предложи новую структуру с типами данных, индексами и ограничениями. Объясни, какие запросы станут быстрее, а какие, возможно, медленнее.
Пример использования: Вы передаете таблицу с повторяющимися данными, и промт предлагает разбить на связанные таблицы с внешними ключами, что уменьшит дублирование и ускорит JOIN. Я использовал это при рефакторинге базы интернет-магазина: размер базы уменьшился на 30%, а скорость агрегаций выросла.
6. Модель данных для MongoDB: проектирование документов
Когда использовать: Нужно решить, как структурировать документы для оптимальной производительности.
Промт:
Спроектируй модель данных для MongoDB для [описание задачи]. Учти: частые запросы — [список], операции записи — [частота]. Предложи структуру документов, включая вложенные массивы или ссылки, и объясни, как это повлияет на производительность чтения и записи.
Пример использования: Для блога с комментариями промт предложит хранить комментарии как массив в документе поста, если их немного, или отдельной коллекцией, если много. Я применял этот подход для приложения с миллионами комментариев, и это сэкономило много ресурсов.
7. Оптимизатор запросов: рефакторинг SQL
Когда использовать: Запрос работает, но медленно. Промт перепишет его в более эффективную форму.
Промт:
Вот SQL-запрос для PostgreSQL, который выполняется долго:
[запрос]
Перепиши его для повышения производительности. Используй JOIN вместо подзапросов, избегай функций в WHERE, применяй оконные функции, если уместно. Объясни, какие изменения ты сделал и почему они ускорят запрос.
Пример использования: Промт преобразует коррелированный подзапрос в JOIN, что уменьшает количество сканирований. Я применил это к запросу отчёта, и время выполнения упало с 15 секунд до 3.
8. Аналитик агрегаций: пайплайны MongoDB
Когда использовать: Пайплайн агрегации тормозит. Промт поможет оптимизировать стадии.
Промт:
Вот пайплайн MongoDB aggregation:
[код]
Он работает медленно. Проанализируй каждую стадию: где можно использовать индексы, какие стадии ($match, $group, $sort) можно переставить, чтобы уменьшить объём данных. Предложи оптимизированную версию.
Пример использования: Промт перемещает $match в начало пайплайна, чтобы отфильтровать данные до $group, что сокращает использование памяти. Я оптимизировал пайплайн для аналитики, и он стал работать в 4 раза быстрее.
9. Инструмент для EXPLAIN: интерактивный анализ
Когда использовать: Вы хотите не только получить совет, но и задать уточняющие вопросы по плану запроса. Промт создаёт «консультанта».
Промт:
Ты — консультант по оптимизации PostgreSQL. Я буду присылать тебе выводы EXPLAIN ANALYZE, а ты будешь задавать мне уточняющие вопросы (например, о размере таблиц, наличии индексов), чтобы дать точные рекомендации. Начни с просьбы прислать план.
Пример использования: Вы отправляете план, ИИ спрашивает: «Есть ли уже индекс на колонку user_id? Какова кардинальность?» — вы отвечаете, и получаете точное решение. Это как диалог с опытным DBA.
10. Чек-лист для оптимизации: полный аудит
Когда использовать: Нужно провести общий аудит базы данных перед релизом.
Промт:
Составь чек-лист для оптимизации PostgreSQL/MongoDB для продакшена. Включи: проверку индексов, анализ медленных запросов (через pg_stat_statements или profile), настройку параметров (shared_buffers, work_mem, WAL), мониторинг. Для каждого пункта дай команду или запрос для проверки.
Пример использования: Вы получаете структурированный список с готовыми SQL-запросами для выявления медленных запросов: SELECT * FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;. Я использовал это для аудита перед запуском, и мы нашли несколько проблем заранее.
Как я использую эти промты в реальной работе
В одном из проектов у нас была база PostgreSQL с таблицей заказов на 10 миллионов строк. Запросы для отчётов висели по 5-10 секунд. Я взял промт №1, скормил вывод EXPLAIN ANALYZE — он показал Seq Scan на 10 млн строк. Промт предложил создать составной индекс на (created_at, status). После создания индекса время выполнения упало до 200 миллисекунд. Это заняло 15 минут вместо трёх часов ручного анализа.
Финальные мысли
Эти промты — не магия, а инструмент. Они работают, если вы понимаете основы SQL и MongoDB. Но они экономят часы на рутине: вместо того чтобы гуглить документацию и экспериментировать, вы получаете готовые решения. Попробуйте один из них сегодня — и вы увидите разницу. А если у вас есть свои проверенные промты для баз данных, поделитесь в комментариях!
Комментарии