SQL-запрос через ИИ — по схеме, с оптимизацией и планом | Aidesk

SQL-запрос через ИИ
схема и задача на входе — запрос, индексы и разбор плана на выходе

Как это работает

Как получить рабочий запрос за пять минут

Три шага от описания отчёта до запроса, проверенного планом

02Опишите результат по-человечески и приложите EXPLAIN
«Топ-20 клиентов по выручке за 90 дней, с количеством заказов и средним чеком, без тех, у кого были возвраты». Для оптимизации — текущий запрос и EXPLAIN ANALYZE целиком: план говорит, где Seq Scan вместо индекса, где сортировка на диске, где вложенный цикл на миллионах.
Совет: добавьте «объясни, почему медленно, прежде чем переписывать» — тогда понятно, что проверять после правки.
03Проверьте план на реальном объёме
Запустите новый запрос с EXPLAIN ANALYZE на боевой копии, сравните время и план с предсказанием модели. Индекс создавайте с CONCURRENTLY и после оценки нагрузки на запись. Если план не тот — вставьте его в чат, модель скорректирует.
Совет: вторую модель попросите проверить корректность: «на каких данных этот запрос даст неверный результат» — NULL в join и дубли находятся так.
Начать → 2 бесплатные генерации после регистрации — без VPN и зарубежной карты

Виды задач

Шесть задач по SQL, с которыми приходят чаще всего

У каждой свой обязательный элемент запроса

📊
Отчёт по описанию
Главное — DDL и формулировка метрики: что считаем, за какой период, с какими исключениями. Агрегации, CTE, оконные функции.
🐢
Ускорить медленный запрос
Главное — EXPLAIN ANALYZE и объём таблиц. Функция в WHERE, join до фильтра, сортировка без индекса — типовые причины.
🧩
Неверный результат
Дубли после join, потерянные строки из-за INNER вместо LEFT, NULL в агрегации. Главное — пример строк, где результат неверен.
🔁
Миграция
Новая колонка с заполнением, разделение таблицы, смена типа на 40 млн строк без простоя. Главное — объём и допустимое окно.
🔄
Перевод между диалектами
MySQL → PostgreSQL, MS SQL → ClickHouse. Главное — исходный запрос и целевая версия: даты, строки, LIMIT и оконные функции различаются.
🧮
Запрос 1С
Язык запросов 1С — отдельный диалект: регистры, виртуальные таблицы остатков, соединения. Главное — конфигурация и имя регистра.

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


Реальные задачи

Что приносят в чат и что получают

Четыре типичные ситуации из работы с базой

ОптимизацияОтчёт по заказам за 40 секунд
Дали

«Postgres 15. Запрос с тремя join и group by выполняется 40 секунд. Вот запрос и explain analyze, DDL ниже. orders 40 млн строк. Что сделать?»

Вернул
  • Разбор плана: Seq Scan по orders, потому что в WHERE стоит date_trunc('day', created_at) — индекс не используется
  • Переписанный WHERE через диапазон created_at >= ... AND created_at < ...
  • Агрегация по order_items в CTE до join с customers вместо после
  • Индекс по (created_at, customer_id) с DDL и CONCURRENTLY
  • Ожидаемый план: Index Scan и HashAggregate; как проверить
ОтчётТоп клиентов без возвратов
Дали

«Нужен запрос: топ-20 клиентов по выручке за последние 90 дней, количество заказов и средний чек, исключить клиентов, у которых был хоть один возврат. Таблицы orders, order_items, returns, customers — DDL прикладываю»

Вернул
  • Запрос с CTE: выручка по заказам, фильтр по дате до агрегации
  • Исключение через NOT EXISTS по returns вместо LEFT JOIN + IS NULL — и почему
  • Средний чек как сумма / количество заказов, а не AVG по строкам items — ловушка объяснена
  • Вариант с оконной функцией для ранга
  • Тестовые данные на 10 строк, чтобы проверить логику
ДублиПосле join сумма удвоилась
Дали

«После join orders с payments сумма заказов в отчёте в два раза больше реальной. Запрос ниже. У некоторых заказов два платежа»

Вернул
  • Причина: join размножает строки заказа по числу платежей, SUM считает заказ дважды
  • Исправление: агрегировать payments в подзапросе до join
  • Запрос для поиска заказов с несколькими платежами — чтобы увидеть масштаб
  • Общее правило: один-ко-многим агрегируется до соединения
  • Проверка: сумма до и после на контрольном периоде
МиграцияДобавить колонку на большой таблице без простоя
Дали

«MySQL 8, таблица events 120 млн строк. Нужно добавить колонку status с заполнением из другой таблицы по event_type. Простой не допускается»

Вернул
  • ADD COLUMN с DEFAULT NULL — мгновенно в MySQL 8, без перестроения
  • Заполнение батчами по 10 000 строк по первичному ключу с паузой — скрипт
  • Индекс после заполнения, не до
  • Как следить за репликацией и лагом во время батчей
  • План отката: что делать, если остановили на середине

В каждом случае модель объяснила причину до кода и дала способ проверить — запрос без проверки на реальном объёме остаётся гипотезой.


Структура

Из чего состоит хороший ответ про SQL

Шесть частей — и ошибка, из-за которой запрос верен на тесте и неверен на проде

ЧастьЧто в нейЧастая ошибка
Диалект и версиязапрос в синтаксисе вашей базыоконные функции в старом MySQL, LIMIT в MS SQL
Запрос с объяснениемчто делает каждый CTE и joinзапрос на 60 строк без единого комментария
Корректность на граничных данныхNULL, дубли, пустые периоды, таймзоныAVG по строкам items вместо среднего чека
Разбор планапочему медленно — по EXPLAIN, а не по интуициииндекс «на всякий случай», который не используется
Индексы с оценкойDDL, что изменится в плане, цена на записьпять индексов на таблицу с активной вставкой
Способ проверитьтестовые строки, контрольная сумма, сравнение планов«должно стать быстрее»

Формулировки

Запросы, после которых SQL приходится переписывать

Слева — как просят, справа — как попросить

✕Напиши запрос для отчёта по продажам
✓PostgreSQL 15, DDL ниже. Выручка по клиентам за 90 дней: количество заказов, средний чек как сумма / число заказов, без клиентов с возвратами. Топ-20. Объясни каждый CTE
✕Ускорь запрос
✓Вот запрос, DDL и EXPLAIN ANALYZE. orders — 40 млн строк. Сначала объясни, почему медленно, потом переписанный запрос и индексы с оценкой, что изменится в плане
✕Почему сумма неправильная
✓После join с payments сумма удвоилась. У части заказов два платежа. Запрос и три строки примера ниже. Найди причину и агрегируй правильно
✕Добавь колонку
✓MySQL 8, events — 120 млн строк, простой не допускается. Колонка status с заполнением по event_type. Батчами, с паузой, план отката
✕Переведи на другой диалект
✓Запрос на MS SQL 2019 ниже, нужен тот же на ClickHouse. Отдельно перечисли, что изменилось: даты, строки, TOP → LIMIT, оконные функции

Честная рамка

Что доверить нейросети, а что проверить самому

Запрос уходит в отчёт и в прод. Модель пишет уверенно — план на реальном объёме обязателен

✅ Доверяем смело
💚
Запрос по DDL — если схема приложена — имена и типы верные, join по ключам
💚
Разбор EXPLAIN — Seq Scan, Nested Loop на миллионах, сортировка на диске — модель читает план лучше, чем кажется
💚
Переписывание — функция в WHERE → диапазон, join после агрегации, NOT EXISTS вместо LEFT JOIN
💚
Граничные случаи — NULL, дубли, пустые периоды — если спросить отдельно
💚
Перевод между диалектами — с перечнем того, что изменилось
🚫 Проверяем руками
🚫
План на реальном объёме — предсказание модели — гипотеза; EXPLAIN ANALYZE на боевой копии — факт
🚫
Индексы на таблицах с записью — каждый индекс — цена на INSERT и UPDATE; решение за DBA
🚫
Контрольные суммы — новый запрос должен давать те же итоги, что старый, на контрольном периоде
🚫
Миграции — на копии, с планом отката, в окно с минимальной нагрузкой
🚫
Версионные различия — функция или синтаксис может отсутствовать в вашей версии — сверить по документации базы

Перед запуском

Восемь проверок запроса

Прогоните сами или попросите вторую модель проверить по пунктам

  1. 01
    Диалект верныйсинтаксис и функции есть в вашей версии базы
  2. 02
    Итоги сходятсяконтрольная сумма на известном периоде совпадает со старым отчётом
  3. 03
    Один-ко-многим агрегировано до joinдублей нет, сумма не удвоена
  4. 04
    NULL учтёнв join, в фильтрах, в агрегации — осознанно
  5. 05
    План проверенEXPLAIN ANALYZE на реальном объёме, время записано
  6. 06
    Индекс оценёниспользуется в плане; нагрузка на запись приемлема; создан CONCURRENTLY
  7. 07
    Границы периодавключительно или нет, таймзона — как в бизнес-правиле
  8. 08
    Запрос прокомментированколлега поймёт каждый CTE без вас

Хороший тест: спросите модель «на каких данных этот запрос даст неверный результат». Ответ обычно короткий и неприятный.



Примеры запросов

Примеры запросов

Нажмите на пример — он вставится в поле выше


Вопросы

Частые вопросы

О схемах, планах, диалектах и границах

Для рабочего запроса — да. Без схемы модель придумает имена колонок и типы, и запрос придётся править руками. CREATE TABLE для участвующих таблиц, вывод \d или SHOW CREATE TABLE — любой из вариантов. Если таблиц много — только те, что участвуют, с ключами и индексами. Данные прикладывать не нужно, достаточно структуры.
Да — Seq Scan там, где ждали индекс, Nested Loop на миллионах строк, Sort на диске, неверная оценка строк планировщиком. По плану модель находит причину точнее, чем по тексту запроса, и объясняет, что должно измениться после правки. Проверяется это повторным EXPLAIN ANALYZE на реальном объёме — предсказание модели остаётся гипотезой до запуска.
Как гипотезе — да, как решению — после двух проверок: индекс действительно используется в новом плане, и цена на запись приемлема для таблицы с активной вставкой. Модель напишет DDL с CONCURRENTLY и скажет, что ожидает в плане; решение принимает тот, кто отвечает за базу.
Да — это отдельный диалект с регистрами, виртуальными таблицами остатков и оборотов, своими соединениями, и модель его знает. Укажите конфигурацию и версию платформы; имена регистров и измерений в вашей редакции сверяются по конфигуратору — попросите модель помечать, в чём не уверена. Подробно — на странице про 1С.
Для запроса нужна схема, а не данные: DDL и, если результат неверный, несколько строк примера с заменёнными значениями. Этого достаточно для любой задачи на странице. Переписка не используется для обучения моделей.
Да. Прикрепите документ, и модель будет работать с ним: сверит формулировки, продолжит в том же стиле, вытащит данные. Для длинных файлов лучше подходит Claude, для таблиц — ChatGPT.
Текст можно забрать прямо из чата или попросить собрать файл: поддерживаются Word (.docx), Excel (.xlsx), PDF, CSV, JSON и XML. Формат PowerPoint (.pptx) пока не поддерживается.
Нет. Aidesk работает в России напрямую, без VPN и зарубежной карты, интерфейс на русском.
После регистрации даётся 2 бесплатные генерации — этого хватит, чтобы прогнать свой документ и посмотреть результат. Дальше работа с файлами, доступ ко всем моделям и большие объёмы — на платных тарифах с оплатой российской картой.

О SQL

SQL-запрос через ИИ

Почему схема важнее описания и где за моделью нужно смотреть

SQL — язык, в котором один и тот же вопрос на разных схемах, объёмах и диалектах даёт разные правильные ответы. Поэтому полезный запрос к модели начинается с DDL и версии базы, а не с «напиши запрос для отчёта». По схеме модель пишет запрос с верными именами и соединениями, объясняет каждый CTE, находит ловушки вроде среднего по строкам вместо среднего чека. По EXPLAIN ANALYZE — объясняет, почему медленно, переписывает и предлагает индексы с оценкой. Проверка плана на реальном объёме, решение об индексе и миграция в окно — за человеком. Работает из России без VPN, запросы можно забрать файлом.

DDL — половина ответа

Имена колонок, типы, ключи, существующие индексы — всё это модель берёт из приложенной схемы, а без неё угадывает. Угадывает правдоподобно, и это хуже, чем если бы ошибалась явно: запрос выглядит верным и падает на имени колонки. CREATE TABLE для участвующих таблиц занимает секунды и экономит три итерации.

План говорит больше, чем запрос

Текст запроса показывает, что хотели; EXPLAIN ANALYZE — что получилось: Seq Scan вместо индекса из-за функции в WHERE, Nested Loop на миллионах строк, сортировка на диске из-за нехватки памяти. Модель читает план и называет причину до переписывания — и это правильный порядок: сначала «почему», потом «как», потом проверка, что «как» изменило именно это.

Корректность — отдельный вопрос

Быстрый запрос с неверным результатом хуже медленного с верным. Типовые ловушки — дубли после join один-ко-многим, потерянные строки из-за INNER вместо LEFT, NULL в агрегации, границы периода и таймзоны. Модель находит их, если спросить отдельно: «на каких данных запрос даст неверный результат». Контрольная сумма на известном периоде — обязательная проверка после любой правки.

Индекс — не бесплатно

Каждый индекс ускоряет чтение и замедляет запись. Модель предложит индекс и объяснит, что изменится в плане, но решение принимает тот, кто знает нагрузку на таблицу. Рабочий порядок: создать CONCURRENTLY на копии, проверить, что план действительно изменился, оценить запись — и только потом в прод.

Где модель опасна

В версиях и объёмах. Синтаксис или функция может отсутствовать в вашей версии базы — сверяется по документации за минуту. Предсказанное ускорение — гипотеза до EXPLAIN ANALYZE на боевом объёме. Миграция на 120 млн строк — только батчами, на копии и с планом отката, который модель напишет, если попросить. Всё остальное — запрос по схеме, разбор плана, переписывание, перевод между диалектами — модель делает стабильно.