Вы когда-нибудь тратили часы на написание сложного запроса, который в итоге выполнялся 20 секунд и падал по таймауту? Я — да. Но с появлением LLM (Large Language Models) рутина SQL-разработки кардинально изменилась. Сегодня нейросети способны не только генерировать запросы, но и объяснять их, оптимизировать и даже проектировать схему базы данных. В этой статье я собрал 15 промтов, которые реально экономят время — от базовых JOIN до шардирования. Каждый промт я протестировал на реальных задачах, поэтому делюсь проверенными формулировками и примерами.
Но сразу предупрежу: промты — это не серебряная пуля. Они работают только в связке с вашим пониманием данных и архитектуры. Ниже вы найдёте не просто список, а гайд, как использовать LLM как старшего коллегу, который всегда на связи.
Базовые промты: с них стоит начать каждому
1. Генерация запроса по описанию на естественном языке
Задача: Быстро получить рабочий SQL-запрос, не вспоминая синтаксис.
Промт:
Ты — эксперт по SQL. Напиши запрос для PostgreSQL, который выведет имена клиентов, сделавших более 5 заказов за последний месяц. Таблицы: customers (id, name, created_at), orders (id, customer_id, created_at). Учитывай, что у клиента может быть 0 заказов.
Пример результата:
SELECT c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
AND o.created_at >= NOW() - INTERVAL '1 month'
GROUP BY c.id, c.name
HAVING COUNT(o.id) > 5;
Почему это работает: LLM понимает контекст, но важно чётко описать схему и бизнес-логику. Указание «LEFT JOIN» в подсказке помогает избежать типичной ошибки — потери клиентов без заказов.
2. Объяснение сложного запроса
Задача: Понять, что делает чужой (или свой давний) запрос.
Промт:
Объясни по шагам, что делает этот MySQL-запрос, и какие результаты он вернёт: SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT 10;
Пример результата:
LLM разберёт каждую часть, объяснит порядок выполнения (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT) и покажет, какие данные попадают в выборку. Это экономит часы на дебаггинге.
3. Перевод запроса между диалектами SQL
Задача: Перенести запрос с MySQL на PostgreSQL или наоборот.
Промт:
Перепиши этот MySQL-запрос для PostgreSQL, учитывая различия в работе с датами и строками: SELECT DATE_FORMAT(created_at, '%Y-%m') AS month, COUNT(*) FROM orders GROUP BY month;
Пример результата:
SELECT TO_CHAR(created_at, 'YYYY-MM') AS month, COUNT(*)
FROM orders
GROUP BY month;
Этот промт спас меня, когда я мигрировал проект между СУБД. Главное — указать целевой диалект и исходный запрос.
4. Написание запроса с JOIN для нескольких таблиц
Задача: Соединить данные из трёх и более таблиц без ошибок.
Промт:
Составь SQL-запрос для MySQL, который выведет список товаров (products), категорий (categories) и поставщиков (suppliers), используя связи: products.category_id → categories.id, products.supplier_id → suppliers.id. Включи только товары с ценой > 100.
Пример результата:
SELECT p.name, c.name AS category, s.name AS supplier
FROM products p
JOIN categories c ON p.category_id = c.id
JOIN suppliers s ON p.supplier_id = s.id
WHERE p.price > 100;
Совет: Указывайте типы JOIN (INNER, LEFT) явно — это снижает риск неверной интерпретации.
Продвинутые промты: для ежедневных задач
5. Оптимизация медленного запроса
Задача: Ускорить запрос, который выполняется слишком долго.
Промт:
Вот мой запрос, он выполняется 15 секунд на PostgreSQL. Проанализируй план выполнения (EXPLAIN ANALYZE) и предложи оптимизации, включая индексы и рефакторинг. Запрос: ... (вставьте ваш запрос и вывод EXPLAIN).
Пример результата:
LLM предложит добавить составной индекс, переписать подзапросы на JOIN или использовать оконные функции. Например, заменить WHERE id IN (SELECT ...) на JOIN.
Важно: Всегда подставляйте реальный EXPLAIN ANALYZE — иначе советы будут общими.
6. Создание индексов для ускорения выборок
Задача: Определить, какие индексы нужны для конкретных запросов.
Промт:
Для этой таблицы и набора запросов предложи оптимальные индексы в PostgreSQL: таблица users (id, email, last_login), запросы: WHERE email = ...; ORDER BY last_login DESC LIMIT 10; JOIN orders ON user_id = ... .
Пример результата:
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_last_login ON users(last_login DESC);
CREATE INDEX idx_orders_user_id ON orders(user_id);
Объяснит, почему покрывающие индексы могут быть лучше, и как проверить через EXPLAIN.
7. Написание запросов с оконными функциями
Задача: Вычислить ранги, скользящие средние, итоги по группам.
Промт:
Используя оконные функции PostgreSQL, выведи для каждого заказа его номер по дате в рамках клиента и разницу с предыдущим заказом. Таблицы: orders (id, customer_id, created_at, total).
Пример результата:
SELECT customer_id, created_at, total,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at) AS order_seq,
total - LAG(total) OVER (PARTITION BY customer_id ORDER BY created_at) AS diff_prev
FROM orders;
Фишка: Попросите LLM объяснить, как работает LAG — это часто забывают.
8. Работа с CTE (Common Table Expressions)
Задача: Разбить сложный запрос на логические части.
Промт:
Перепиши этот запрос с использованием CTE для улучшения читаемости: SELECT ... (сложный запрос с вложенными подзапросами).
Пример результата:
WITH recent_orders AS (
SELECT customer_id, SUM(total) AS total_spent
FROM orders
WHERE created_at >= NOW() - INTERVAL '1 year'
GROUP BY customer_id
)
SELECT c.name, r.total_spent
FROM customers c
JOIN recent_orders r ON r.customer_id = c.id
WHERE r.total_spent > 1000;
CTE делают запрос понятным, а LLM помогает структурировать логику.
9. Генерация тестовых данных
Задача: Создать синтетические данные для проверки запросов.
Промт:
Сгенерируй SQL для PostgreSQL, который создаст 1000 тестовых записей в таблице users (id serial, name text, email text, created_at timestamp) со случайными данными (имена, email, даты за последний год).
Пример результата:
INSERT INTO users (name, email, created_at)
SELECT
'User_' || generate_series(1,1000),
'user'
|| generate_series(1,1000) || '@example.com',
NOW() - (random() * 365 || ' days')::interval
FROM generate_series(1,1000);
Этот промт не раз выручал при нагрузочном тестировании.
10. Написание запросов для MongoDB с агрегацией
Задача: Получить данные из MongoDB, используя aggregation pipeline.
Промт:
Напиши MongoDB aggregation pipeline, который найдёт средний чек заказа по каждому клиенту за последние 30 дней и отсортирует по убыванию. Коллекции: customers (_id, name), orders (customer_id, total, created_at).
Пример результата:
db.orders.aggregate([
{ $match: { created_at: { $gte: new Date(new Date().setDate(new Date().getDate() - 30)) } } },
{ $group: { _id: "$customer_id", avg_total: { $avg: "$total" } } },
{ $sort: { avg_total: -1 } },
{ $lookup: { from: "customers", localField: "_id", foreignField: "_id", as: "customer" } },
{ $unwind: "$customer" },
{ $project: { name: "$customer.name", avg_total: 1 } }
])
Важно: Указывайте точные названия полей — от этого зависит корректность.
Экспертные промты: для архитекторов и тимлидов
11. Проектирование схемы базы данных
Задача: Спроектировать схему БД под описанные требования.
Промт:
Спроектируй схему PostgreSQL для интернет-магазина: есть пользователи, товары, заказы, корзина. Укажи таблицы, связи, первичные и внешние ключи, а также ограничения целостности. Учти, что заказ может содержать несколько товаров.
Пример результата:
LLM предложит таблицы users, products, orders, order_items, carts, с правильными связями many-to-many и индексами. Это отличная отправная точка для обсуждения с командой.
12. Решение проблем с блокировками и дедлоками
Задача: Диагностировать и устранить взаимоблокировки.
Промт:
В PostgreSQL возникают дедлоки в таблице orders при конкурентной вставке. Предложи стратегии решения: изоляция транзакций, порядок блокировок, использование NOWAIT. Приведи пример кода с правильным порядком.
Пример результата:
LLM объяснит, что нужно всегда блокировать таблицы в одинаковом порядке, и предложит использовать SELECT ... FOR UPDATE NOWAIT и обработку исключений.
13. Оптимизация запросов для больших данных (партиционирование)
Задача: Ускорить выборки по таблице с миллионами строк.
Промт:
Таблица logs содержит 100 млн строк, запросы часто фильтруют по created_at. Предложи стратегию партиционирования в PostgreSQL, включая тип (RANGE, LIST) и пример создания партиций по месяцам.
Пример результата:
CREATE TABLE logs (
id bigint,
message text,
created_at timestamp
) PARTITION BY RANGE (created_at);
CREATE TABLE logs_2026_08 PARTITION OF logs
FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');
Также посоветует автоматическое создание партиций через pg_partman.
14. Шардирование данных в MongoDB
Задача: Распределить данные по кластеру.
Промт:
Объясни, как настроить шардирование в MongoDB для коллекции orders по ключу customer_id. Опиши шаги: включение шардирования на БД, выбор ключа, создание индекса, включение шардирования коллекции. Приведи команды.
Пример результата:
sh.enableSharding("shop");
db.orders.createIndex({ customer_id: "hashed" });
sh.shardCollection("shop.orders", { customer_id: "hashed" });
LLM предупредит о выборе ключа и влиянии на read/write distribution.
15. Генерация миграций для изменения схемы
Задача: Создать безопасные миграции для изменений в БД.
Промт:
Напиши SQL-миграцию для MySQL, которая добавляет поле status в таблицу orders с дефолтным значением 'pending', но так, чтобы не заблокировать таблицу на время выполнения (используй ONLINE ALTER или поэтапное обновление).
Пример результата:
ALTER TABLE orders ADD COLUMN status ENUM('pending', 'paid', 'shipped') NOT NULL DEFAULT 'pending';
Для больших таблиц LLM порекомендует использовать инструменты вроде gh-ost.
Практический кейс: как я ускорил отчёт в 10 раз
Недавно мне нужно было оптимизировать отчёт по продажам. Исходный запрос с несколькими JOIN и подзапросами выполнялся 25 секунд. Я использовал промт №5, вставил EXPLAIN ANALYZE, и LLM предложила:
- Заменить подзапрос в SELECT на LEFT JOIN.
- Добавить составной индекс на
orders(customer_id, created_at). - Использовать
FILTERвместоCASE WHENдля агрегатов.
После изменений запрос стал выполняться за 2,3 секунды — ускорение в 10 раз. Эти промты действительно работают, если использовать их как инструмент для анализа, а не для слепого копирования.
Выводы
Промты для SQL — это не магия, а способ ускорить рутину и повысить качество кода. Главное — формулировать задачи чётко, давать контекст и проверять результат. Начните с базовых промтов, постепенно переходя к сложным. И помните: LLM — отличный помощник, но финальное решение всегда за вами. Держите эту подборку под рукой, и ваши запросы станут быстрее и читабельнее. А если хотите прокачаться дальше — загляните в наш блог, где мы разбираем реальные кейсы оптимизации БД.
Изображение: [ссылка на картинку про SQL]
Комментарии