Альтернатива чатам с ИИ для анализа и оптимизации SQL запросов

[mrprogre]

Тем, кто использует постгрес будет полезен explain.tensor.ru. Вставляете план запроса и он вам рекомендует очень детально что поправить.

[Dradmin]

спасибо за ссылку, интересный сервис

[akakoychenko]

Вцелом, если под рукой есть ddl всей бд (а он, как правило, редко теряет актуальность), то копипастнуть его в o3, как будто бы, не то, чтобы сложно

Но запросы пишет просто песня. Включая серьезную аналитику на десяток CTE. Если совсем сложное что-то надо, можно ещё пару подсказок дать, типа, считаю, что тебе понадобятся вот эти таблицы

[apcs660]

тоже заинтересовало, что может модель создать без метадатанных?

Недавно смотрел создание запросов для graph DB (neo4j), cypher query - там честно метаданные отдаются в контекст.

Если не ошибаюсь, на хабре был пост от участника российского postgres о том как их командой планируется встроить модельку с созданием sql запроса в базу - доступ к метаданным есть, но все равно модель ошибается с созданием запроса.

Может быть не настоящий сварщик - не будет ли удобнее обучать модель создавать запросы в формате json или подобном более удобном для обучения AI и предварительной проверки а затем переводить его в SQL? Или оставить упрощенное что то типа JPA в Java, не залезать полноценно в ньюансы SQL и конкретной базы? Модель хороша для универсальных высокоуровневых решений - натаскал ее, дал метаданные дата объектов и используй для разных баз с адаптером на MCP или просто функцией.

[Dradmin]

Согласен, при хорошем DDL и чётком контексте LLM действительно может писать отличные запросы особенно если немного “подсказать направление”.

Я пытался сделать инструмент, который избавляет от необходимости всё это проговаривать в чате: просто вставляешь запрос, выбираешь СУБД, и (если хочется глубже) можно добавить схему, индексы, EXPLAIN - всё структурировано, без промтов и многословия.

Цель не заменить подход с DDL + чат, а упростить первые шаги и ускорить получение качественных рекомендаций.

[apcs660]

кстати, почему бы не запрашивать ddl функцией/MCP? думаю все это потихоньку добавится. Более того, мы не будем работать с одиночными агентами, а сразу с наборами агентов.

[AKimovd]

На основе чего сервис даёт рекомендации?

[Dradmin]

Сервис использует GPT4, которая анализирует сам SQL-запрос, выбранную СУБД и (опционально) дополнительный контекст - схему, индексы и план выполнения запроса (EXPLAIN/ANALYZE).

[PEMOHT_OKOH]

Для mssql есть?

[Dradmin]

Да Есть, пока отключил потому что сложно протестировать. Если поможете протестировать то быстро появится )

[kkomelin]

на ажуровском облачном потестируйте

[Dradmin]

Уже сделали, и пользователи используют)

[kkomelin]

быстро вы

[Dradmin]

Добавил mssql, попробуйте пожалуйста

[rozhnev]

Я давно сделал похожую штуку на своём сайте sqlize.online Можно выполнять SQL запросы онлайн и пользоваться подсказкой от ИИ

[Dradmin]

Спасибо за ссылку, полезный сервис

[Akina]

Фигня. Обгадился на несложном вопросе.

Задача. Есть таблица приходов и таблица расходов. Нужно посчитать и получить одну запись с тремя полями - сумма прихода, сумма расхода, разница между ними.

Решение влоб очевидно:

SELECT 
    (SELECT SUM(rent) FROM income) AS sum_income,  
    (SELECT SUM(cost) FROM expenses) AS sum_expenses,
    (SELECT SUM(rent) FROM income) - (SELECT SUM(cost) FROM expenses) AS difference;

Но оптимальностью не пахнет - MySQL сообразит, что подзапросы независимы, но вряд ли догадается, что они ещё и попарно идентичны.

Попробуем сгрузить это ИИ... и что же он нам предлагает? А это нагромождение мудрости предлагает нам учинить CROSS JOIN!!!

SELECT
    SUM(i.rent) AS sum_income,
    SUM(e.cost) AS sum_expenses,
    SUM(i.rent) - SUM(e.cost) AS difference
FROM
    income i
    CROSS JOIN expenses e;

О да! Мало того, что он ничего не знает про JOIN multiplying, так ещё и критически увеличивает количество записей, которые придётся обработать серверу. На этом фоне дополнительный бред про индексацию суммируемого поля, которая якобы может дать эффект, можно даже не учитывать.

Это при том, что решение-то очевидно - нужно просто вынести подзапросы в CTE.

WITH
cte1 (sum_income) AS (
  SELECT SUM(rent) FROM income
  ),
cte2 (sum_expenses) AS (
  SELECT SUM(cost) FROM expenses
  )
SELECT sum_income,
       sum_expenses,
       sum_income - sum_expenses AS difference
FROM cte1 
CROSS JOIN cte2;

А в случае MySQL можно решить и более изящно:

SELECT (SELECT sum(rent) FROM income) AS sum_income,
       (SELECT sum(cost) FROM expenses) AS sum_expenses,
       (SELECT sum_income - sum_expenses) AS difference;

В общем, не дорос ещё ИИ до подобных задач.

[Dradmin]

Спасибо большое за обратную связь. Да, замечаний много. Буду дорабатывать чтобы более сложные задачи можно было решать.