🗓️ SQL-трюк: как быстро найти "дыры" в данных по датам

В аналитике часто нужно понять, за какие дни нет записей — например, продаж или логов.
Вместо сложных процедур можно сгенерировать календарь через generate_series() (Postgres) и сделать LEFT JOIN к данным. Так вы мгновенно выявите пропуски и сможете строить непрерывные временные ряды.

-- Дни без заказов за последние 30 дней
WITH calendar AS (
  SELECT generate_series(
    current_date - interval '30 days',
    current_date,
    interval '1 day'
  )::date AS day
),
orders_per_day AS (
  SELECT
    order_ts::date AS day,
    COUNT(*)       AS orders_count
  FROM sales
  WHERE order_ts >= current_date - interval '30 days'
  GROUP BY order_ts::date
)
SELECT
  c.day,
  COALESCE(o.orders_count, 0) AS orders_count
FROM calendar c
LEFT JOIN orders_per_day o USING(day)
WHERE o.orders_count IS NULL
ORDER BY c.day;

https://www.youtube.com/shorts/CAkHyUx6iiU

#SQL #Postgres #DataAnalytics #generate_series

Продвинутый SQL-прием: partial index вместо “универсального” индекса

Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё.

Например, есть таблица заказов:

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Обычный индекс:

CREATE INDEX idx_orders_user_status
ON orders(user_id, status);

Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее.

Если чаще всего нужны только активные заказы, можно сделать partial index:

CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';

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

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

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

Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false.

#sql #postgresql #database #backend

Вопрос на SQL собеседовании.

Какой оператор имеет больший приоритет AND или OR (если они используются совместно)?

Ответ:

AND имеет больший приоритет, нежели OR

#sql #собеседование

Одна маленькая звёздочка в SQL может незаметно просадить весь backend.

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

Но потом в таблицу добавляют тяжёлый JSON, аватар, длинный текст или служебные данные. И старый код внезапно начинает таскать лишние мегабайты на каждый запрос.

Дальше всё сыпется по цепочке: растёт трафик, запросы тормозят, память уходит быстрее, кэш работает хуже, а любое изменение схемы становится рискованнее.

Поэтому в продакшене лучше выбирать только те поля, которые реально нужны приложению.

Звёздочка удобна для быстрой проверки. Но в рабочем коде это та самая лень, которая потом больно бьёт по продакшену.

#sql #backend #database #postgresql #mysql #разработка #программирование #devtips #webdev

💡 SQL-трюк: сравнивайте `NULL` без костылей

В PostgreSQL обычное сравнение может неожиданно сломать условие:

SELECT NULL = NULL;

Результат:

NULL

Потому что NULL означает «неизвестное значение», а не конкретное значение.

Из-за этого часто пишут громоздкие условия:

WHERE a = b
   OR (a IS NULL AND b IS NULL)

Но есть оператор, о котором многие забывают:

a IS NOT DISTINCT FROM b

Он работает как NULL-safe equality:

SELECT NULL IS NOT DISTINCT FROM NULL; -- true
SELECT 10   IS NOT DISTINCT FROM 10;   -- true
SELECT 10   IS NOT DISTINCT FROM NULL; -- false

Есть и обратный вариант:

a IS DISTINCT FROM b

Например, удобно искать реально изменившиеся значения:

SELECT *
FROM old_data o
JOIN new_data n USING (id)
WHERE o.email IS DISTINCT FROM n.email;

Если оба email = NULL, строка не считается изменённой.

Без этого обычное:

o.email <> n.email

может просто вернуть NULL и пропустить изменение.

Особенно полезно при синхронизации данных, аудите изменений, ETL и UPSERT-логике.

#SQL #PostgreSQL #Database

⚡️ QueryTuner - open-source инструмент, который разбирает SQL-запрос и показывает, почему он может тормозить.

Подключаться к базе вообще не обязательно. Можно просто вставить SQL и получить диагностику.

Поддерживаются сразу 5 диалектов:

- PostgreSQL
- MySQL
- Oracle
- SQL Server
- SQLite

Внутри два уровня анализа.

1. Детерминированный heuristic engine

Он мгновенно ищет типичные anti-patterns:

- SELECT *
- функции внутри WHERE
- leading wildcard в LIKE
- потенциально отсутствующие индексы
- ORDER BY без ограничения результата
- другие проблемы производительности

Сейчас заявлено 12 правил, и для них не нужны ни LLM, ни внешний API.
2. Опциональный AI-слой

Можно подключить Qwen через Hugging Face или OpenAI. Тогда QueryTuner умеет:

- объяснять проблему человеческим языком;
- переписывать запрос;
- предлагать CREATE INDEX;
- объяснять, зачем конкретный индекс нужен.

Особенно интересно, что можно передать ещё и CREATE TABLE DDL. Тогда рекомендации становятся schema-aware: инструмент видит реальные таблицы, колонки и существующие индексы.

Например, для такого запроса:

SELECT *
FROM orders
WHERE YEAR(created_at) = 2026;

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

#SQL #PostgreSQL #Database #OpenSource #DataEngineering

https://github.com/AutoShiftOps/querytuner

SQL: Один NULL в списке, и NOT IN возвращает ноль строк


WHERE id NOT IN (1, 2, NULL) раскрывается в id <> 1 AND id <> 2 AND id <> NULL. Последнее сравнение всегда даёт UNKNOWN, а WHERE пропускает только TRUE, поэтому запрос молча возвращает пустой результат. Одно неизвестное значение отравляет весь фильтр. Если в подзапросе возможен NULL, бери NOT EXISTS: он на NULL не ломается и читается понятнее, чем костыль с IS NOT NULL.

#sql #deathnote

⚡️ SQL-задача с подвохом

Что вернёт этот запрос в PostgreSQL?

CREATE TABLE payments (
    id     int,
    amount int
);

INSERT INTO payments VALUES
    (1, 100),
    (2, 100),
    (3, 200);

SELECT
    id,
    amount,
    SUM(amount) OVER (ORDER BY amount) AS total
FROM payments
ORDER BY id;

Многие ожидают:

1 | 100 | 100
2 | 100 | 200
3 | 200 | 400

Но результат будет другим:


1 | 100 | 200
2 | 100 | 200
3 | 200 | 400


По умолчанию PostgreSQL использует окно RANGE ... CURRENT ROW. Строки с одинаковым amount считаются равными соседями и попадают в окно вместе.

Для построчного накопления нужно указать ROWS:


SUM(amount) OVER (
ORDER BY amount, id
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)


#SQL #PostgreSQL #Database