DeepSeek · Разработка

DeepSeek V3 для работы с SQL

SQL — редкий случай, когда ответ модели проверяется мгновенно: запустил на копии, посмотрел результат. Поэтому платить за самую дорогую модель здесь незачем — гораздо важнее возможность крутить запрос десять раз подряд, ничего не считая. DeepSeek V3 стоит 2 токена за обращение, это 6000 запросов на месячной подписке и 150 на суточной за один рубль.

Почему DeepSeek V3 подходит для этой задачи

Цена ошибки в SQL низкая, а скорость обратной связи высокая: неверный запрос либо не выполнится, либо вернёт очевидно странные числа. Это меняет экономику — вместо одного дорогого «идеального» ответа выгоднее десять дешёвых итераций. При 2 токенах за обращение цикл «получил, запустил, вернулся с ошибкой» практически бесплатен, и именно так SQL и пишется на практике.

DeepSeek V3 уверенно держит синтаксис разных диалектов и типовые конструкции, из-за которых обычно и лезут в справочник: оконные функции, рекурсивные CTE, группировки с фильтрацией, работа с интервалами дат. Если явно назвать СУБД и версию, ответ обычно запускается без правок — а разница между PostgreSQL и MySQL в этих местах существенная.

Второе применение, которое недооценивают, — объяснение чужого запроса. Легаси-витрина на двести строк с пятью подзапросами разбирается быстрее, если попросить построчный комментарий и список мест, где логика может ломаться. При такой цене это дешевле, чем полчаса собственного чтения, и его же можно повторить для каждого запроса в отчёте.

Какие входные данные подготовить

Схема таблиц в виде CREATE TABLE или хотя бы список колонок с типами и ключами. Описания словами недостаточно — из него модель придумает названия полей.

Диалект и версия: PostgreSQL 16, MySQL 8, ClickHouse, SQLite. Синтаксис дат, оконных функций и upsert различается принципиально.

Порядок величин и индексы: миллион строк или миллиард — это разные запросы, даже если результат одинаковый.

Образец нужного результата: список колонок и две строки-примера. Это снимает большую часть недопонимания в постановке задачи.

Текст ошибки целиком и вывод EXPLAIN, если вы чините существующий запрос, а не пишете новый.

Пошаговый процесс

Дайте схему, а не описание

Скопируйте DDL нужных таблиц прямо в запрос. Любое словесное описание («там есть таблица заказов с датой и суммой») приводит к тому, что модель выдумывает имена колонок, и запрос не запускается. Хуже, если она угадает похожее имя существующей колонки с другим смыслом — тогда запрос отработает и посчитает не то.

Сформулируйте результат таблицей

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

Запускайте на копии и с ограничением

Первый прогон всегда на тестовой базе или с LIMIT. Смотрите не только на числа, но и на количество строк: если после соединения их стало больше, чем в исходной таблице, где-то размножились дубли — самая частая и самая незаметная ошибка.

Тормозит — отдавайте план, а не просьбу ускорить

Запрос «оптимизируй» даёт косметическую переписку без эффекта. Работает другое: выполнить EXPLAIN ANALYZE и отдать вывод модели с вопросом, что здесь дороже всего и почему планировщик выбрал именно этот путь. Дальше решение обычно сводится к индексу или к переписыванию одного подзапроса.

Просите объяснение построчно

Даже для рабочего запроса стоит потратить два токена на построчный разбор. Во-первых, так ловятся логические ошибки, которых не видно по результату на маленьких данных. Во-вторых, вы начинаете писать такие запросы сами и обращаетесь к модели всё реже.

Пример готового промпта

Диалект и версия: [POSTGRESQL 16 / MYSQL 8 / CLICKHOUSE].

Схема:
"""
[CREATE TABLE ...]
"""

Объёмы: [СКОЛЬКО СТРОК В КАЖДОЙ ТАБЛИЦЕ]. Существующие индексы: [СПИСОК].

Нужен результат такого вида:
"""
[КОЛОНКИ И ДВЕ СТРОКИ-ПРИМЕРА]
"""

Словами: [ЧТО СЧИТАЕМ, ЗА КАКОЙ ПЕРИОД, В КАКОМ ЧАСОВОМ ПОЯСЕ].

Выдай четыре части.

1. Запрос. Только таблицы и колонки из схемы, ничего не придумывай. Если данных в схеме не хватает — скажи об этом вместо запроса.
2. Построчное объяснение: что делает каждый блок и зачем он нужен.
3. Где этот запрос может посчитать неверно: дубли после соединений, поведение NULL, границы периода, часовой пояс, строки без совпадений.
4. Проверочный запрос, который считает то же самое другим способом, чтобы я сверил результаты.

Не предлагай UPDATE, DELETE и изменения схемы. Если нужен индекс — отдельной строкой напиши, какой именно и почему он поможет.

Пункт с проверочным запросом окупается сразу: два независимо посчитанных числа либо совпадают, либо мгновенно показывают, что логика где-то поехала.

Как проверить результат

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

Количество строк до и после соединений проверено — рост числа строк означает размножение дублей по неуникальному ключу.

Проверено поведение NULL: конструкции с NOT IN, сравнения и агрегаты ведут себя не так, как ожидает интуиция.

Ни один UPDATE или DELETE не выполнен без предварительного SELECT тех же строк и без транзакции, которую можно откатить.

Типичные ошибки

Просить запрос без схемы

Без DDL модель придумает правдоподобные названия таблиц и колонок. Хорошо, если запрос просто упадёт с ошибкой — плохо, когда в базе случайно есть колонка с таким же именем и другим смыслом: запрос отработает, выдаст красивые числа, и они попадут в отчёт. Схема в запросе стоит тридцати секунд и снимает целый класс проблем.

Выполнять изменяющие запросы вслепую

UPDATE или DELETE от модели, запущенный сразу на боевой базе, — классическая история с потерей данных. Правило простое: сначала тот же WHERE в виде SELECT, смотрим, сколько и каких строк попало; потом транзакция; и только потом фиксация. Ни один сгенерированный запрос не должен идти в прод без этого цикла.

Верить оптимизации без плана выполнения

На просьбу ускорить модель перепишет запрос красивее: заменит подзапрос на CTE, добавит явные соединения. Читаться станет лучше, работать — так же, потому что узкое место обычно в отсутствующем индексе или в приведении типов, из-за которого индекс не используется. Единственный способ понять — посмотреть EXPLAIN до и после.

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

Почему для SQL советуют самую дешёвую модель?

Потому что результат проверяется запуском за секунды, а не экспертизой. Дорогая модель не даст выигрыша, который вы заметите, зато при 2 токенах можно позволить себе десять итераций подряд — а именно так SQL и доводится до рабочего состояния.

Можно ли давать модели реальную схему базы?

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

Сколько запросов даёт подписка?

DeepSeek V3 стоит 2 токена. Месячная подписка за 999 рублей — это 6000 обращений, недельная за 399 рублей тоже с большим запасом. Даже суточный доступ за 1 рубль даёт около 150 запросов, чего хватает на целый рабочий день с базой.

Модель поможет разобрать чужой запрос?

Это одно из лучших её применений. Вставьте запрос и попросите построчный комментарий плюс список мест, где логика может ломаться: дубли, NULL, границы периодов. На легаси-отчётах экономит часы.

Что делать, если запрос работает, но медленно?

Выполните EXPLAIN ANALYZE и отдайте вывод модели с вопросом, какой шаг дороже всего и почему выбран такой план. Просьба «ускорь» без плана даёт косметику. Решением чаще всего оказывается индекс или снятие приведения типов, из-за которого индекс не применялся.

Модель DeepSeek V3 доступна в FatherGPT: без VPN, картой РФ, единый баланс токенов на все нейросети. Переключайтесь между моделями в одном чате — под каждую задачу своя.