7 готовых промтов для написания SQL-запросов и оптимизации баз данных

7 готовых промтов для написания SQL-запросов и оптимизации баз данных

Представьте ситуацию: вам нужно срочно написать сложный SQL-запрос для отчёта, а времени на вспоминание синтаксиса оконных функций или настройку индексов нет. Или вы сталкиваетесь с медленным выполнением запроса, который «съедает» всю память сервера. Согласно опросу Stack Overflow 2025 года, SQL остаётся вторым по популярности языком программирования среди профессионалов — его используют более 65% разработчиков. При этом, по данным исследования Redgate (2025), более 40% DBA и разработчиков тратят до 30% рабочего времени на оптимизацию запросов.

Современные языковые модели (вроде GPT-4o, Claude 3.5 Sonnet или Gemini 2.0) способны не только генерировать SQL-код, но и анализировать планы запросов, предлагать индексы и даже находить узкие места. В этой статье — подборка из 7 конкретных промтов, которые вы можете скопировать и использовать прямо сейчас. Каждый промт включает задачу, пояснение и пример использования.

1. Промт для генерации SQL-запроса по описанию на естественном языке

Задача: Быстро получить корректный SQL-запрос, когда вы знаете, какие данные нужны, но не помните точный синтаксис.

Промт:

Ты — эксперт по SQL с опытом работы с PostgreSQL 16. Напиши SQL-запрос для следующей задачи. Используй современный синтаксис (CTE, оконные функции, JOIN вместо подзапросов, если это улучшает читаемость). Добавь комментарии к каждой части запроса. Задача: [опишите задачу, например: «вывести топ-5 клиентов по сумме заказов за последний месяц, с указанием количества заказов и средней суммы чека»]. Укажи, какие индексы помогут ускорить этот запрос.

Пример использования:
- Задача: «Найти сотрудников, которые продали товаров на сумму больше 100 000 рублей в каждом из последних 3 месяцев, и вывести их ID, имя и общую сумму продаж за квартал».
- Результат: Модель сгенерирует запрос с оконной функцией RANK(), фильтром по дате и подзапросом для агрегации по месяцам, а также порекомендует индексы на order_date и employee_id.

2. Промт для оптимизации медленного запроса

Задача: Разобраться, почему существующий запрос работает медленно, и получить исправленную версию.

Промт:

Вот план выполнения (EXPLAIN ANALYZE) и текст медленного SQL-запроса. Проанализируй узкие места: sequential scans, неправильные оценки строк, отсутствие индексов, Nested Loops vs Hash Join. Предложи конкретные улучшения: 1) изменённый запрос, 2) какие индексы создать, 3) возможно ли переписать логику. Если нужно — предложи денормализацию или материализованные представления. Запрос: [вставьте запрос]. План: [вставьте EXPLAIN ANALYZE].

Пример использования:
- DBA замечает, что запрос с множественными JOIN выполняется 45 секунд. После анализа модель указывает на Full Table Scan по таблице orders (из-за функции DATE(created_at) в WHERE) и рекомендует заменить на created_at >= CURRENT_DATE - INTERVAL '30 days' и добавить индекс по created_at. Время выполнения падает до 200 мс.

3. Промт для генерации схемы базы данных по описанию бизнес-логики

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

Промт:

Спроектируй схему реляционной базы данных для [опишите домен: «интернет-магазин книг с авторами, жанрами, заказами и отзывами»]. Используй PostgreSQL. Включи: таблицы с первичными и внешними ключами, ограничения (CHECK, NOT NULL), индексы для часто используемых полей, комментарии к таблицам и колонкам. Учти требования нормализации до 3НФ, но если нужна производительность — предложи разумную денормализацию. Выведи DDL-скрипт.

Пример использования:
- Стартап запускает сервис доставки еды. Модель генерирует 8 таблиц (users, restaurants, menu_items, orders, order_items, deliveries, reviews, payments) с правильными типами данных, внешними ключами и индексами на user_id, restaurant_id, order_date. Это экономит 2-3 часа ручного проектирования.

4. Промт для переписывания запроса в более производительный стиль

Задача: Преобразовать медленный или нечитаемый запрос в оптимальную форму.

Промт:

Перепиши следующий SQL-запрос, соблюдая правила: 1) замени коррелированные подзапросы на JOIN или оконные функции, 2) убери ненужные DISTINCT, 3) используй EXISTS вместо IN, если подзапрос большой, 4) вынеси одинаковые условия в CTE. Объясни каждое изменение. Исходный запрос: [вставьте запрос].

Пример использования:
- Исходный запрос использует SELECT DISTINCT на 10 колонках с подзапросом WHERE id IN (SELECT ...). Модель заменяет на EXISTS и оконную функцию ROW_NUMBER() для дедупликации. Количество строк в плане сокращается с 1 млн до 10 тыс., время выполнения — с 8 секунд до 0,3 секунды.

5. Промт для диагностики проблем с блокировками и deadlocks

Задача: Выявить причины взаимоблокировок или долгих ожиданий в конкурентной среде.

Промт:

У меня в PostgreSQL происходят частые deadlocks и блокировки при конкурентном доступе к таблице [название таблицы]. Вот вывод pg_locks и pg_stat_activity в момент проблемы: [вставьте данные]. Проанализируй: какие транзакции блокируют друг друга, какой уровень изоляции используется, какие индексы могли бы снизить блокировки. Предложи решение: изменение порядка операций, использование NOWAIT, переход на READ COMMITTED, партиционирование или оптимистичные блокировки.

Пример использования:
- В системе бронирования отелей два пользователя одновременно пытаются забронировать последний номер. Модель выявляет, что блокировка на уровне строки происходит из-за отсутствия индекса по room_id и status, и рекомендует добавить составной индекс и использовать SELECT ... FOR UPDATE NOWAIT с повторной попыткой. Deadlocks исчезают.

6. Промт для написания миграций и скриптов рефакторинга

Задача: Создать безопасный скрипт изменения схемы без потери данных.

Промт:

Напиши SQL-скрипт миграции для PostgreSQL, который: 1) добавляет колонку discount_price типа NUMERIC(10,2) с DEFAULT NULL в таблицу products, 2) заполняет её значением price * 0.9 для всех товаров с category_id = 5, 3) создаёт индекс на новой колонке, 4) добавляет CHECK constraint, что discount_price < price. Используй транзакцию с BEGIN/COMMIT и добавь комментарии. Учти, что таблица может содержать 2 млн строк — используй батчи (по 10 000 строк), чтобы не заблокировать таблицу надолго.

Пример использования:
- Разработчик применяет скрипт в 3 утра в транзакции. Благодаря батчам, блокировка строк длится не более 2 секунд, и приложение не уходит в тайм-аут. Индекс создаётся с параметром CONCURRENTLY, чтобы не блокировать записи.

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

Задача: Автоматически описать существующую базу данных или набор запросов.

Промт:

Вот DDL и набор часто используемых запросов для базы данных [название]. Сгенерируй документацию в формате Markdown: 1) описание каждой таблицы и её назначение, 2) список ключевых запросов с пояснением, что они делают и какие индексы используют, 3) ER-диаграмма в текстовом виде (описание связей). Используй понятные формулировки для новых членов команды. DDL: [вставьте DDL]. Запросы: [вставьте запросы].

Пример использования:
- В проект приходит новый разработчик. Вместо того чтобы читать 200 строк DDL, он получает документ с описанием: «Таблица orders хранит заказы, связана с users через user_id, индекс на status ускоряет фильтрацию активных заказов». Время онбординга сокращается с 2 дней до 2 часов.

Как использовать эти промты максимально эффективно

1. Адаптируйте под свою СУБД. Если вы используете MySQL, BigQuery или SQL Server, явно укажите это в начале промта. Диалекты различаются: например, оконные функции и CTE поддерживаются не везде одинаково.
2. Давайте контекст. Чем точнее описание задачи (названия таблиц, типы данных, объём строк), тем качественнее ответ.
3. Проверяйте результат. Ни одна модель не идеальна: всегда запускайте сгенерированный запрос в тестовой среде, проверяйте EXPLAIN ANALYZE и убеждайтесь, что индексы созданы до выполнения.
4. Используйте итерации. Если первый вариант не подходит, уточните: «Попробуй использовать Hash Join вместо Nested Loops» или «Упрости условие WHERE».

Заключение

Промт-инжиниринг для SQL — это не замена знаниям, а мощный ускоритель. Вместо того чтобы тратить часы на написание сложного отчёта или отладку медленного запроса, вы можете за 5 минут получить рабочий вариант, который останется лишь проверить и донастроить. Опрос от O'Reilly (2025) показал, что 72% инженеров данных уже используют AI-ассистентов для написания запросов, и эта доля растёт.

Начните с одного промта из списка — например, попробуйте оптимизировать запрос, который давно «висел» в очереди на рефакторинг. Результат, скорее всего, вас удивит.

Использованные источники: Stack Overflow Annual Developer Survey 2025, Redgate State of Database DevOps 2025, O'Reilly AI Adoption in Data Engineering Report 2025.