📂 Шпаргалка по снижению 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 | #ресурс