Отладка SQL: синтаксические, логические ошибки и ошибки с NULL

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

Синтаксические ошибки: пропущенная запятая и неверное ключевое слово

Синтаксическая ошибка означает одно: СУБД не смогла разобрать текст запроса как грамматически корректный SQL. Выполнения не происходит — движок останавливается на стадии разбора.

Рассмотрим два типичных случая.

Пропущенная запятая между выражениями. Чтобы соседнее имя нельзя было принять за допустимый псевдоним, возьмём квалифицированные столбцы:

SELECT o.customer_id o.total_amount
FROM orders AS o;

SQLite остановится около точки во втором имени: после o.customer_id он ожидал запятую или FROM, а конструкцию o.total_amount уже не может разобрать как псевдоним. Исправление:

SELECT o.customer_id, o.total_amount
FROM orders AS o;

Важно: запрос SELECT customer_id name FROM orders; ошибку не вызовет — SQL прочитает name как неявный псевдоним. Поэтому при отладке проверяйте, не превратился ли пропуск запятой в формально допустимый алиас.

Опечатка в ключевом слове. Например:

SELECT customer_id, total_amount
FORM orders;

Сообщение может указывать на orders, хотя ошибочно слово перед ним: написано FORM вместо FROM. Парсер сообщает место, где разбор окончательно стал невозможен, а не обязательно символ, где человек впервые ошибся.

То же правило работает при неверном порядке предложений:

SELECT customer_id
WHERE total_amount > 1000
FROM orders;

Порядок фиксирован: SELECT → FROM → WHERE → GROUP BY → HAVING → ORDER BY. Если сообщение указывает на правильный с виду токен, посмотрите на одно-два слова левее.