😍 zasqlpython — платформа для изучения и практики SQL!

Сайт позволяет изучать SQL с нуля и сразу закреплять материал на практике. Бесплатный курс включает 10 уроков и 92 задачи с автоматической проверкой прямо в браузере. После базового курса можно перейти к SQL-тренажёру с сотнями задач повышенной сложности и заданиями в формате собеседований.

📌 Оставляю ссылочку: zasqlpython.ru

➡️ SQL Ready | #ресурс

📂 Шпаргалка по снижению Latency в Backend-системах!

Например, Cache позволяет отдавать часто используемые данные без обращения к базе данных, а Load Balancer распределяет запросы между несколькими серверами, повышая скорость и отказоустойчивость приложения.

На картинке — основные стратегии уменьшения задержек в высоконагруженных системах.

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Почему OFFSET деградирует на больших таблицах!

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

Есть таблица:

events(
    id BIGINT,
    user_id BIGINT,
    payload JSONB,
    created_at TIMESTAMPTZ
)

Типичная пагинация:

SELECT
    id,
    user_id,
    created_at
FROM events
ORDER BY created_at DESC
LIMIT 50 OFFSET 1000000;

Кажется, что база должна просто пропустить миллион строк и вернуть следующие 50. Но SQL-движок не может сделать настоящий прыжок через OFFSET. Ему нужно обработать строки до нужной позиции, а потом отбросить их.

Без подходящего индекса это может выглядеть так: база читает строки, определяет порядок сортировки, обрабатывает OFFSET + LIMIT записей, выбрасывает ненужные строки и возвращает только нужный результат.

Даже если есть индекс:

CREATE INDEX idx_events_created_at
ON events(created_at DESC);

ситуация всё равно не идеальна.

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

Например:

LIMIT 50 OFFSET 1000000;

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

Для глубоких страниц обычно используют keyset pagination (cursor pagination). Вместо номера страницы передаётся последнее значение из предыдущего результата:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE created_at < '2026-08-01 12:00:00'
ORDER BY created_at DESC
LIMIT 50;

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

Но одного created_at недостаточно, если несколько событий имеют одинаковое время.

Например:

2026-08-01 12:00:00

2026-08-01 12:00:00

2026-08-01 12:00:00

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

CREATE INDEX idx_events_cursor
ON events(created_at DESC, id DESC);

И запрос становится:

SELECT
    id,
    user_id,
    created_at
FROM events
WHERE (created_at, id) < ('2026-08-01 12:00:00', 1500000)
ORDER BY created_at DESC, id DESC
LIMIT 50;

Теперь курсор точно определяет позицию в индексе.

Главное преимущество такого подхода — стоимость запроса зависит в основном от размера страницы, а не от глубины пагинации. Первая страница:

LIMIT 50;

и страница после миллионов записей:

WHERE (created_at, id) < (...)
LIMIT 50;

используют один и тот же принцип: найти позицию в B-tree индексе и продолжить чтение.

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

🔥 Делаем вывод: OFFSET удобен для разработки, но плохо масштабируется на больших объёмах данных. Для больших таблиц лучше использовать keyset pagination с составным индексом и стабильным курсором.

➡️ SQL Ready | #практика

✍️ Попалась интересная статья на Хабре: «Почему в БД на PostgreSQL популярен тип numeric?»!

В этой статье:
• Разберётесь, почему для денег и точных расчётов часто выбирают numeric, несмотря на его производительность;
• Узнаете, чем на практике отличаются numeric, целые типы и double precision;
• Посмотрите, какие требования к точности и округлению предъявляют SQL, платёжные системы и финансовые стандарты.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

Настройки только для одного запроса!

Необязательно менять statement_timeout, work_mem или другие параметры для всей сессии. SET LOCAL действует только до конца текущей транзакции.

BEGIN;

SET LOCAL lock_timeout = '500ms';

ALTER TABLE orders
ADD COLUMN source text;

COMMIT;

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

BEGIN;

SET LOCAL work_mem = '512MB';

SELECT customer_id, count(*)
FROM events
GROUP BY customer_id;

COMMIT;

Можно даже точечно дать тяжёлому запросу больше памяти, не увеличивая work_mem для остальных запросов соединения.

🔥 SET LOCAL позволяет тюнить PostgreSQL под конкретную операцию и автоматически возвращает настройки назад после COMMIT или ROLLBACK.

➡️ SQL Ready | #совет

😎 PostgreSQL FAQ — справочник по частым проблемам и вопросам!

Здесь собраны разборы типичных ситуаций при работе с PostgreSQL: проблемы с подключением и настройкой, ошибки в SQL, оптимизация медленных запросов, партиционирование, размеры таблиц, timestamp with time zone, pg_dump и другие нюансы. Есть конкретные команды, примеры диагностики и рекомендации по тому, какие данные собирать для поиска проблем.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Проверяйте преобразование без исключений!

Обычный cast падает с ошибкой, если значение нельзя преобразовать. Из-за этого в ETL и в запросах к промежуточным данным часто приходится заранее чистить данные или писать PL/pgSQL с обработкой исключений.

SELECT value::integer
FROM staging;
-- ERROR при первом плохом значении

PostgreSQL умеет проверять, является ли строка допустимым значением конкретного типа, не вызывая ошибку.

SELECT value
FROM staging
WHERE pg_input_is_valid(value, 'integer');

Типом может быть не только integer:

SELECT pg_input_is_valid('192.168.1.10', 'inet');
SELECT pg_input_is_valid('550e8400-e29b-41d4-a716-446655440000', 'uuid');
SELECT pg_input_is_valid('2026-09-08', 'date');

А pg_input_error_info() позволяет получить причину, почему преобразование невозможно.

SELECT *
FROM pg_input_error_info('2026-02-30', 'date');

🔥 pg_input_is_valid() позволяет валидировать грязные входные данные средствами самой системы типов PostgreSQL.

➡️ SQL Ready | #совет

❤️ SQL-шпаргалка — основные конструкции и приёмы работы с базами данных!

Справочник по SQL с примерами запросов и пояснениями. Здесь на небольших таблицах разобраны INNER, LEFT, RIGHT, FULL и CROSS JOIN, а также показаны различия синтаксиса между PostgreSQL, MySQL, SQLite и SQL Server. Для команд указано, что именно они делают и в каких ситуациях применяются.

📌 Оставляю ссылочку: tools.sitebyme.ru

➡️ SQL Ready | #ресурс

📂 Шпаргалка по структурам данных!

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

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

Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

😍 PostgreSQL Zero to Hero — большой русскоязычный материал по изучению PostgreSQL!

Здесь разобраны основы SQL, проектирование баз данных, индексы, транзакции, MVCC, WAL, оптимизация запросов, репликация, бэкапы и многое другое. Подойдёт разработчикам, которые хотят системно изучить PostgreSQL и разобраться не только с SQL, но и с архитектурой, производительностью, эксплуатацией базы данных.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

Хочешь заняться архитектурой, а вместо этого третий час пишешь одну и ту же типовую миграцию? Теперь это можно делегировать.

CatCode - агент, который работает с проектом сам: пишет миграции, чинит запросы, гоняет тесты, пока ты занят чем-то более интересным. Доступны все топовые модели:

😒 Claude Opus 5
🤖 GPT-6 Astra
😐 Grok 4.6
и многие другие.

Умный свитчер решит фоном, кому что отдать - рутину дешёвой модели, сложный таск - нейросети покруче. Один лимит дешевле зоопарка отдельных подписок - всего 900 рублей в месяц.

Оплата картой РФ или СБП, работает без VPN. Первые задачи бесплатно, просто зарегистрируйся и попробуй.

Делегируй рутину уже сегодня: catcode.dev

Оконный фрейм по группам значений!

ROWS считает физические строки. GROUPS считает группы строк с одинаковым значением ORDER BY.

SELECT price,
       count(*) OVER (
           ORDER BY price
           GROUPS BETWEEN 1 PRECEDING AND 1 FOLLOWING
       )
FROM products;

Если по одной цене находится 50 товаров, вся эта пачка считается одной группой. Поэтому можно строить окна относительно соседних значений, не вычисляя dense_rank() и не добавляя ещё один уровень запроса.

Ещё интереснее EXCLUDE, который можно использовать прямо внутри оконного фрейма:

SELECT id,
       avg(score) OVER (
           ORDER BY created_at
           ROWS BETWEEN 10 PRECEDING AND 10 FOLLOWING
           EXCLUDE CURRENT ROW
       ) AS neighbors_avg
FROM measurements;

Среднее здесь считается по соседним строкам, но текущая строка автоматически исключается.

SELECT price,
       sum(amount) OVER (
           ORDER BY price
           GROUPS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
           EXCLUDE GROUP
       )
FROM sales;

EXCLUDE GROUP исключит из расчёта всю текущую peer-группу, а не только одну строку.

🔥 GROUPS + EXCLUDE позволяют описывать сложные окна непосредственно в OVER, где обычно появляются dense_rank(), дополнительные CTE и self join.

➡️ SQL Ready | #совет

Составные индексы: правила проектирования и типичные ошибки!

Составные индексы используются для ускорения запросов по нескольким колонкам, но порядок полей внутри индекса напрямую влияет на его эффективность.

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

CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT NOT NULL,
    status VARCHAR(30),
    created_at TIMESTAMP NOT NULL,
    amount NUMERIC(10,2)
);

Обычный индекс на каждую колонку не всегда является оптимальным решением. СУБД может использовать несколько индексов одновременно, но такой план не всегда будет эффективнее одного правильно спроектированного составного индекса.

CREATE INDEX idx_orders_user
ON orders(user_id);

CREATE INDEX idx_orders_created_at
ON orders(created_at);

Для частого сценария поиска заказов конкретного пользователя за период лучше создать составной индекс:

CREATE INDEX idx_orders_user_created_at
ON orders(user_id, created_at);

Такой индекс эффективно работает для запросов, где используется первая колонка индекса или полный набор колонок.

SELECT *
FROM orders
WHERE user_id = 42
AND created_at >= '2026-01-01';

В B-tree индексе данные сначала сортируются по user_id, а внутри одинаковых значений user_id — по created_at.

Поэтому СУБД быстро находит записи пользователя и затем выполняет поиск по диапазону дат. Также индекс будет использоваться:

SELECT *
FROM orders
WHERE user_id = 42;

Но он плохо подходит для поиска только по второй колонке:

SELECT *
FROM orders
WHERE created_at >= '2026-01-01';

Причина в структуре B-tree: данные сначала организованы по первой колонке индекса.

Для такого запроса отдельный индекс по дате будет более подходящим:

CREATE INDEX idx_orders_created_at
ON orders(created_at);

Ещё одна распространённая ошибка — добавление большого количества колонок в индекс.

CREATE INDEX idx_orders_all_columns
ON orders(user_id, status, created_at, amount);

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

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

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE user_id = 42
AND status = 'paid'
ORDER BY created_at DESC;

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

CREATE INDEX idx_orders_user_status_created_at
ON orders(user_id, status, created_at DESC);

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

🔥 Главное правило простое: индекс создаётся под реальные запросы приложения, а не просто под структуру таблицы.

➡️ SQL Ready | #практика