При разработке нового дашборда на основе старого SQL-запроса обнаружилась ошибка, которая долго оставалась незамеченной: две таблицы джойнились по ID заявки, и нулевые значения в этом ключе привели к массовому некорректному присвоению данных. Разбираем, как такое происходит и почему это трудно поймать.
Как выглядела проблема
В запросе участвовали две таблицы, связанные через INNER JOIN по полю ID заявки. В левой таблице оказалось 5 миллионов строк с ID = 0 — и само по себе это было допустимо по логике системы. В правой таблице существовала ровно одна запись с нулём, которую следовало отфильтровать ещё на этапе подготовки данных, но этого не было сделано.
В результате все 5 миллионов строк с нулевым ID из левой таблицы присоединились к единственной «нулевой» записи из правой — и получили её атрибуты. Данные из одной строки равномерно распределились по всему диапазону дат, не создав никакого визуального пика или аномалии, которую легко заметить.
Почему ошибку сложно заметить
Именно равномерность распределения делает эту ошибку особенно опасной. Если бы данные исказились локально — в одну дату или по одному сегменту — аномалия бросилась бы в глаза сразу. Но когда 5 миллионов строк получают одно и то же значение и размазываются по всей временной оси, общая картина выглядит правдоподобно.
Ошибку удалось обнаружить только благодаря контекстному знанию: коллега заметил провалы в данных по выходным дням в одном из разрезов. Это противоречило графику работы сотрудников и указало на несостыковку. Без такого доменного знания ошибка могла бы оставаться незамеченной долгое время.
Что сделать на практике
- Перед JOIN проверяйте, какие значения ключа соединения встречаются в обеих таблицах — особенно нули и NULL.
- Фильтруйте «технические» нули (ID = 0, ID IS NULL) до выполнения JOIN, если они не несут бизнес-смысла.
- При работе со старыми запросами не доверяйте им автоматически — проводите базовую проверку: количество строк до и после JOIN, распределение ключевых метрик.
- Добавляйте в дашборд срезы, которые позволяют выявить логические аномалии: по дням недели, по типу события, по сегментам с известным поведением.
- Документируйте допустимые значения ключей соединения в описании источника данных.
Вывод
Нулевые значения в ключах JOIN — тихая угроза: они не вызывают ошибок выполнения запроса и не создают очевидных визуальных аномалий. Проверка нулей и NULL в полях соединения должна быть обязательным шагом ревью любого SQL-запроса перед его использованием в продуктовых отчётах и дашбордах.