🗄️ SQL

Короткий ответ Идемпотентность означает одинаковое логическое состояние после одного и нескольких запусков одного batch. Сначала определите бизнес-ключ и правило победы версии; лишь затем выбирайте диалект и физическую модель. Как это работает подробнее В PostgreSQL уникальный индекс делает конфликт атомарным, но условие обновления должно запрещать старой версии перетирать новую. В BigQuery source MERGE обязан иметь максимум одну строку на target key, иначе запрос завершится ошибкой или логика станет неоднозначной. ClickHouse оптимизирован для append. ReplacingMergeTree(version) хранит новые версии, а физическое удаление старых происходит асинхронно; корректное чтение требует argMax, materialized view или осознанного FINAL. Пример кода Что использовать на практике Используйте закрытый watermark. Фиксируйте нижнюю и верхнюю границы batch и продвигайте watermark только после успеха. Оставляйте lookback. Повторно читайте недавнее окно для поздних данных, полагаясь на идемпотентную запись. Проверяйте конкуренцию.

Читать полностьюbigquery

Короткий ответ Нужно читать план выполнения «снизу вверх» (от самых глубоких узлов к верхним), сравнивать оценку числа строк (rows) с фактическим числом (actual rows) на каждом шаге и искать узел с наибольшим фактическим временем — это и есть основная точка замедления. Как это работает подробнее Как это работает: PostgreSQL выполняет план как дерево операций (сканирование таблиц, соединения, сортировки, агрегации); каждый узел в EXPLAIN ANALYZE показывает actual time (включает время всех дочерних узлов) и actual rows. Большое расхождение между оценкой (rows=... в плане) и фактическим числом строк часто говорит об устаревшей статистике таблицы. Пример кода Что использовать на практике На практике: типичные «красные флаги» — Seq Scan на крупной таблице там, где ожидался индексный доступ, Nested Loop с большим количеством итераций по внешней таблице без индекса на внутренней, а также отдельный заметный по времени узел Sort или Hash, который может говорить о нехватке work_mem и уходе сортировки на диск. Проверка:

Читать полностьюexplain

Короткий ответ В SQL NULL означает неизвестное значение. Выражение email = NULL даёт UNKNOWN, а фильтр WHERE сохраняет только строки, для которых условие равно TRUE. Как это работает подробнее SQL использует трёхзначную логику: TRUE, FALSE и UNKNOWN. Сравнение неизвестного значения через =, <> или != не может подтвердить ни равенство, ни неравенство. Проверки IS NULL и IS NOT NULL специально предназначены для отсутствующих значений и возвращают обычный логический результат. Пример кода Что использовать на практике Различайте пропуск и пустую строку. Для обоих случаев используйте email IS NULL OR email = ''. Для отрицания подзапроса. Предпочитайте NOT EXISTS, если результат подзапроса может содержать NULL. Подводные камни Неверное отрицание. email != NULL также возвращает UNKNOWN, а не заполненные email. NOT IN. Один NULL в списке способен сделать проверку отсутствия неизвестной для всех строк.

Читать полностьюnull

Короткий ответ WHERE фильтрует строки до GROUP BY, а HAVING фильтрует группы после агрегации. Поэтому условие на SUM или COUNT размещают в HAVING. Как это работает подробнее Логический порядок обработки запроса: FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY. На этапе WHERE агрегатные значения ещё не вычислены. Ранний фильтр уменьшает объём данных для соединения и группировки. Если условие относится к отдельной строке, его обычно выгоднее и понятнее записать в WHERE. Пример кода Что использовать на практике WHERE. Ограничивайте период, статус исходной строки и другие неагрегированные признаки. HAVING. Оставляйте группы по условиям вроде SUM(amount) > 1000 или COUNT(*) > 5. Подводные камни Агрегат в WHERE. Запись WHERE SUM(amount) > 1000 некорректна, потому что сумма ещё не рассчитана. Поздняя фильтрация. Перенос обычного условия в HAVING может заставить СУБД обработать лишние строки.

Читать полностьюaggregations

Короткий ответ ROW_NUMBER() всегда присваивает уникальные последовательные номера даже при равных значениях, RANK() даёт одинаковый ранг «ничьим», но пропускает следующие номера, а DENSE_RANK() даёт одинаковый ранг «ничьим» без пропусков в нумерации. Как это работает подробнее все три функции работают над окном, заданным PARTITION BY/ORDER BY. При трёх строках с одинаковым значением на 2-й позиции: ROW_NUMBER() даст 1,2,3,4 произвольно (в зависимости от порядка «ничьих», который без дополнительного критерия сортировки недетерминирован); RANK() даст 1,2,2,4 (пропускает 3); DENSE_RANK() даст 1,2,2,3. Пример кода Что использовать на практике выбор функции зависит от задачи: для «каждому ряду — свой уникальный номер» (например, для дедупликации или пагинации) нужен ROW_NUMBER(); для «официального» рейтинга, где важно показать настоящее место с учётом ничьих (как в спорте), — RANK(); для рейтинга без «дырок» в номерах — DENSE_RANK(). Если два заказа имеют одинаковую максимальную сумму, rnk у обоих будет 1, у drnk

Читать полностьюdense-rank

Короткий ответ EXPLAIN показывает, какой план выполнения СУБД выбрала для запроса — какие таблицы и в каком порядке читаются, используются ли индексы или полное сканирование таблицы — и помогает понять, почему запрос работает медленно, до того как его запустят на полных данных. Как это работает подробнее EXPLAIN (без ANALYZE) строит предполагаемый план на основе статистики таблиц без фактического выполнения запроса, а EXPLAIN ANALYZE реально выполняет запрос и добавляет к плану фактическое время и количество обработанных строк на каждом шаге. Пример кода Что использовать на практике на базовом уровне аналитику достаточно уметь заметить признаки проблемы — например, «Seq Scan» (полное сканирование таблицы) на очень большой таблице там, где ожидался индексный поиск, или то, что оценка числа строк на одном из шагов плана сильно расходится с фактической. Если в плане видно «Seq Scan on orders», а таблица на миллионы строк, это сигнал задуматься об индексе на customer_id. Проверка: после создания индекса повторный

Читать полностьюexplain

Короткий ответ Скорее всего произошёл «fan-out» — соединение таблицы заказов (одна строка на заказ) с таблицей позиций (несколько строк на заказ) размножило каждую строку заказа на число позиций в нём, и последующий SUM(orders.total_amount) просуммировал одно и то же значение несколько раз. Как это работает подробнее Как это работает: JOIN по своей природе образует по одной строке результата на каждую пару совпавших строк с обеих сторон; если на один order_id в order_items приходится 3 строки, то после JOIN поле orders.total_amount окажется повторено 3 раза — и SUM по нему будет втрое больше реального. Пример кода Что использовать на практике На практике: правильный способ зависит от задачи: если нужна сумма заказов — считать SUM(DISTINCT ...) небезопасно (может отфильтровать легитимные совпадающие суммы у разных заказов), поэтому лучше либо агрегировать order_items до одной строки на заказ заранее (в CTE), либо считать сумму orders.total_amount из отдельного запроса без JOIN к позициям, а детализацию по това

Читать полностьюaggregation

Короткий ответ При росте команды неявные знания перестают работать. Цель стандарта — сделать безопасный путь самым простым, а не заставить каждого заполнять длинный чек-лист для любого одноразового запроса. Как это работает подробнее Разделите артефакты по риску: исследовательский запрос, сертифицированная модель и executive-отчёт требуют разной строгости. Общие шаблоны должны фиксировать зерно, источник, часовой пояс, правила NULL и ожидаемую кардинальность JOIN. Автотесты дают больше пользы, чем ручные запреты: уникальность ключа, not-null, accepted values, freshness, reconciliation с источником и контрольные бизнес-примеры. Документация должна жить рядом с кодом и обновляться тем же pull request. Пример кода Что использовать на практике Начните с инцидентов. Выберите два-три класса ошибок с наибольшей стоимостью для команды. Автоматизируйте по умолчанию. Formatter, lint и тесты не должны зависеть от памяти ревьюера. Измеряйте пользу. Следите за дефектами, временем ревью, onboarding и долей повторного испол

Читать полностьюanalytics-engineering

Короткий ответ LIMIT n (PostgreSQL, MySQL, ClickHouse, BigQuery) ставится после ORDER BY в конце запроса, TOP n в T-SQL (SQL Server) ставится сразу после SELECT, а FETCH FIRST n ROWS ONLY — стандартный ANSI SQL синтаксис, поддерживаемый, например, в PostgreSQL и Oracle как альтернатива LIMIT; при переносе запроса между диалектами синтаксис ограничения строк почти всегда нужно переписывать вручную. Как это работает подробнее все три конструкции решают одну задачу — ограничить количество возвращаемых строк — но различаются синтаксическим расположением и иногда поведением при наличии «ничьих» на границе отсечки (для которых может потребоваться WITH TIES в T-SQL или FETCH FIRST ... WITH TIES в ANSI SQL, что не всегда есть в упрощённом LIMIT). Пример кода Что использовать на практике Практика. при переносе SQL-логики между системами (например, миграция отчётов с SQL Server на PostgreSQL или с PostgreSQL на BigQuery) стоит явно пройтись по каждому запросу и заменить диалект-специфичный синтаксис, а не надеяться на

Читать полностьюclickhouse