Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.
Инструмент работает так: пользователь вставляет запрос, выбирает СУБД и получает результат — рекомендации, оптимизированную версию, а также может добавить контекст (EXPLAIN, схема, статистика) для более точного анализа.
За первый месяц сервис использовали более 1000 человек и продолжают пользоваться.
Поэтому решил опубликовать пост с результатами, проблемами и внести изменения в продукт для улучшения пользовательского опыта.
Результаты
1. Распределение СУБД
MySQL — 40%
PostgreSQL — 38%
SQL Server — 20%
MariaDB — 1%
SQLite — 1%
PostgreSQL почти сравнялся с MySQL, что стало для меня неожиданностью. SQL Server показал значительно большую долю, чем я предполагал.
2. Размеры запросов
Более 10 КБ — 7%
Более 5 КБ — 13%
Более 1 КБ — 35%
Половина запросов — компактные. Но есть и довольно крупные, особенно с аналитикой на основе CTE.
3. Статистика обращений к сервису по странам
Обнаруженные проблемы
1. Поддержка SQL Server
SQL Server начали запрашивать в первый же день. Поддержка была реализована и протестирована на реальных запросах.
2. Ограничения по размеру
Из-за лимитов в токенах некоторые запросы (>10 КБ) не обрабатывались. Теперь лимит увеличен до 80 КБ.
3. Качество рекомендаций
Иногда ИИ давал поверхностные или ошибочные советы, даже при относительно простых запросах. Особенно это проявлялось при отсутствии схемы и EXPLAIN. Доработан стандартный режим работы, чтобы уменьшить количество таких ситуаций.
Что изменилось
1. Добавлена поддержка MS SQL Server
2. Новый режим анализа: Deep Analysis
Многошаговый процесс, доступный для зарегистрированных пользователей, который включает:
Построение гипотез и рекомендаций на основе текста запроса и контекста.
Проверка уместности и отсеивание слабых рекомендаций.
Генерация оптимизированного запроса.
3. Добавлены метки уверенности в рекомендациях.
4. Добавлена история запросов
Пользователи с авторизацией (GitHub, Google) могут видеть и повторно открывать предыдущие запросы и рекомендации.
5. Публичные отчёты
Результатами анализа можно поделиться по ссылке. Это удобно для обсуждения с коллегами, получения внешней оценки или документации изменений.
У анонимных пользователей отчёты автоматически публичные.
У зарегистрированных — есть выбор публиковать или нет.
Попробовать
Инструмент открыт и доступен по адресу:
Буду благодарен за любую обратную связь
Комментарии (9)
Krenodator
19.08.2025 19:02Всё упирается в качество подсказок. Если ИИ ошибается даже на простых кейсах, то никакой интерфейс это не спасёт
rPman
Главная беда ИИ - галлюцинации, и чем больше запрос, тем больше шансов ошибки, которые он внесет в запрос, а обнаружить эти ошибки может быть очень сложно.
Отличный пример таких ошибок, без сложной аналитики - даешь список чего либо (в формате csv например) и просишь провести с этим списком какие-нибудь операции, например поменять порядок строк, колонок, убрать колонку,.. сразу видно что даже топовые модели уже на 20 записях начинают терять их.
Та же причина, что 'вынуждает' модели терять информацию, будет ломать sql запросы в самых неожиданных местах.
p.s. программисты, кто пытается использовать ИИ для таких оптимизаций, должны работать с ИИ в очень тесном контакте, модифицируя промпт, анализируя результат на живых данных, с примерами, и кстати, полнота информации о базе данных и стратегиях сохранения их в базе (раскрытие что есть один ко многим, на сколько 'один' одинок а на сколько 'многим' множится может менять многое и обеспечивать возможности для оптимизаций)
правильный подход - создать набор тестов, на фиксированном наборе данных, и прогонять получаемый запрос на них
Dradmin Автор
Да, согласен, с длинным контекстом иногда тяжеловато общаться.
Попробовал минимизировать эти проблемы с помощью добавления оценки уверенности в рекомендации и многошагового анализа, когда AI проверяет свои гипотезы и отбрасывает слабые.