Хотите узнать секрет оптимизации SQL-запросов?

Очень важно понимать порядок выполнения.
В SQL-запросе операторы выполняются в следующем порядке:

1. FROM / JOIN
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. DISTINCT
7. ORDER BY
8. LIMIT / OFFSET

📲 Мы в MAX

#db

👉 @database_info

Как упростить работу с кластером через веб‑интерфейс OpenSearch Dashboards

Присоединяйтесь к вебинару от Selectel, чтобы разобраться на практике, как развернуть кластер СУБД OpenSearch в облаке за несколько минут и управлять им с помощью веб-интерфейса OpenSearch Dashboards. Узнаете, как легко настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами.

📍 Онлайн
⏰ 16 июля в 15:00
👤 Кому будет полезно: сисадминам, архитекторам, администраторам баз данных, бэкэнд-разработчикам, техлидам


Регистрируйтесь ➡️ https://slc.tl/3po0z

Больше мероприятий для ИТ-специалистов в канале @selectel_events. Подписывайтесь!

Реклама. АО "Селектел". erid:2W5zFK5Svmo

Индексы в PostgreSQL: Часть 1 — B-Tree

Если ты создавал индекс в PostgreSQL по умолчанию, значит, это B-Tree.
Но как он работает и когда он реально полезен?

Что это такое?

B-Tree индекс — сбалансированное дерево поиска.
PostgreSQL автоматически использует его для:

=\` (равенство)
> < >= <= (сравнения)
BETWEEN
LIKE 'abc%' (только префикс, без %abc%).

Пример:

CREATE INDEX idx_users_email ON users (email);
SELECT * FROM users WHERE email = 'test@example.com';

Запрос не будет сканировать всю таблицу — он сразу пойдёт по дереву.

Подводные камни:

1. Не работает для произвольных LIKE:
LIKE '%abc%' → индекс не поможет.
2. Осторожно с функциями:
WHERE LOWER(email) = 'abc' — индекс не используется. Нужен функциональный индекс:

   CREATE INDEX idx_users_email_lower ON users (LOWER(email));
   

3. Многоколонковые индексы:
Порядок важен. (a, b) используется при фильтре по a или по a AND b, но не только по b.

Когда ставить?

- Уникальные поля (email, username).
- Часто используемые фильтры и JOIN-колонки.
- Сортировки (ORDER BY created_at DESC).

Вывод:
B-Tree — твой “универсальный солдат”. Но не пихай его на всё подряд. Перед добавлением — смотри EXPLAIN (ANALYZE).

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

📲 Мы в MAX

#db

👉 @database_info

🔒 Почему одна "невинная" транзакция может положить продакшн

Классическая ситуация: разработчик открывает транзакцию, делает выборку, потом какой-то API-запрос наружу (например, к платёжному шлюзу), и только потом коммитит. Транзакция висит открытой 3-5 секунд вместо миллисекунд. Локально всё ок, тесты зелёные. В проде — деградация через пару часов.

Что происходит под капотом в PostgreSQL (MVCC):

1. VACUUM не может убрать мёртвые строки. Пока жива хоть одна старая транзакция, движок обязан хранить все версии строк, которые теоретически могут быть видны в её snapshot. UPDATE/DELETE копится в виде dead tuples, автовакуум работает, но эффективность падает.

2. Table bloat. Таблица физически растёт, индексы разбухают, страницы всё реже помещаются в shared_buffers — растёт I/O, падает cache hit ratio.

3. xmin horizon не двигается. Это глобальная граница, до которой можно чистить старые версии. Одна зависшая транзакция держит её на месте для ВСЕЙ базы, а не только для своей таблицы.

4. Реплики страдают отдельно. На hot standby с hot_standby_feedback = on долгая транзакция на реплике заставляет primary тоже не вакуумить нужные строки — эффект расползается по кластеру.

Как ловить:

SELECT pid, now() - xact_start AS duration, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC
LIMIT 10;

Плюс idle in transaction — отдельная категория боли: транзакция открыта, а коннекшен вообще ничего не делает (забыли закоммитить/роллбэкнуть). Лечится через idle_in_transaction_session_timeout.

Правило для сеньора: транзакция должна жить ровно столько, сколько нужно для консистентности данных — не больше. Любой сетевой вызов, любая тяжёлая бизнес-логика — только вне транзакции или в отдельном коротком шаге.

#postgresql #databases #mvcc

📲 Мы в MAX

#db

👉 @database_info

🗄 Нормализация баз данных: от 1NF до 4NF

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

🔹 Первая нормальная форма — 1NF
Каждая ячейка содержит только одно атомарное значение. Нельзя хранить несколько товаров в одном поле — каждый товар должен находиться в отдельной строке.

🔹 Вторая нормальная форма — 2NF
Таблица соответствует 1NF, а каждый неключевой столбец полностью зависит от всего составного первичного ключа. Данные о заказе и его позициях обычно разделяются на разные таблицы.

🔹 Третья нормальная форма — 3NF
Устраняются транзитивные зависимости. Например, имя и регион клиента лучше хранить в таблице клиентов, а в заказе оставить только идентификатор клиента.

🔹 Нормальная форма Бойса — Кодда, BCNF
Усиленная версия 3NF: любой столбец, от которого зависят другие данные, должен быть потенциальным ключом.

🔹 Четвёртая нормальная форма — 4NF
Устраняет независимые многозначные зависимости. Например, навыки сотрудника и его проекты следует хранить в отдельных таблицах.

✅ Результат нормализации — меньше дубликатов, проще обновление данных и более предсказуемая работа базы.

А до какой нормальной формы вы обычно доводите структуру БД?

#базыданных #SQL #нормализация #database #программирование #разработка


📲 Мы в MAX

👉 @database_info

Антипаттерны JOIN-ов в SQL и как их избежать

JOIN - мощная штука, но может легко превратиться в генератор тормозов и дублей. Вот топ-4 ловушек:

1️⃣ Забыли условие соединения

SELECT *
FROM orders
JOIN customers;

Без ON это картезианское произведение - каждая строка первой таблицы умножается на все строки второй. Легко получить миллионы ненужных записей.
✅ Как избежать: Всегда указывай условие соединения.


2️⃣ JOIN по неиндексированным колонкам
Если соединяешь большие таблицы по полю без индекса - готовься ждать.
✅ Как избежать: Добавь индекс на ключи соединения.

CREATE INDEX idx_orders_customer_id ON orders(customer_id);

3️⃣ Фильтры в WHERE вместо ON

-- Плохо
FROM orders
LEFT JOIN customers ON orders.customer_id = customers.id
WHERE customers.region = 'EU';

LEFT JOIN превратился в INNER JOIN, потому что фильтр в WHERE отсекает NULL-строки.
✅ Как избежать: Фильтруй в ON, если хочешь сохранить LEFT JOIN:

LEFT JOIN customers 
  ON orders.customer_id = customers.id AND customers.region = 'EU';

4️⃣ SELECT *** в сложных JOIN-ах
Такая выборка тянет все колонки всех таблиц. Много лишних данных + риск коллизии имён колонок.
✅ Как избежать: Явно указывай нужные поля.


💡 Вывод: JOIN - как скальпель. В умелых руках ускоряет, в неумелых - режет производительность.

Сохрани, чтобы не резануть базу не туда ✂️

📲 Мы в MAX

#db

👉 @database_info

7 обязательных стратегий для масштабирования вашей базы данных

📲 Мы в MAX

#db

👉 @database_info

Немного юмора)

📲 Мы в MAX

#db

👉 @database_info

🚨 Антипаттерн: Почему OFFSET убивает твою базу (и как делать пагинацию правильно)

Привет! Если вы когда-нибудь реализовывали каталог товаров или ленту новостей, то наверняка писали запрос с LIMIT и OFFSET. Для небольших таблиц это работает отлично, но как только проект взлетает и данных становится много, база начинает задыхаться. Давайте разберем, почему так происходит и как это лечить.

❌ Как мы делаем обычно:

SELECT id, title, created_at 
FROM articles 
ORDER BY created_at DESC 
LIMIT 50 OFFSET 100000;

В чем подвох? База данных не умеет «магически» прыгать на 100 000-ю строку. Ей придется прочитать, отсортировать (если нет подходящего индекса) и отбросить первые 100 000 строк, чтобы вернуть вам всего 50. Чем глубже пользователь листает страницы, тем медленнее работает запрос. Нагрузка на CPU и диски растет экспоненциально.

✅ Как делать правильно:

Вместо того чтобы говорить базе «пропусти N строк», мы говорим ей «дай мне 50 записей, которые идут сразу после последней записи, которую я уже видел».

SELECT id, title, created_at 
FROM articles 
WHERE created_at < '2023-10-25 14:00:00' -- дата из последней записи на предыдущей странице
ORDER BY created_at DESC 
LIMIT 50;

Этот запрос мгновенно найдет нужное место по индексу (B-Tree) и прочитает ровно 50 строк. Никакой лишней работы!

🛠 Важный нюанс:
Если поле created_at не уникально (две статьи вышли в одну секунду), предыдущий запрос может пропустить данные. Используйте уникальный «тайбрейкер» - например, id. В PostgreSQL это можно сделать очень элегантно с помощью кортежей (Row Values):

SELECT id, title, created_at 
FROM articles 
WHERE (created_at, id) < ('2023-10-25 14:00:00', 10543)
ORDER BY created_at DESC, id DESC
LIMIT 50;

(Не забудьте создать составной индекс: `CREATE INDEX idx_articles_created_id ON articles (created_at DESC, id DESC);`)

📌 Итог:

• OFFSET / LIMIT: Ок для админок с небольшим трафиком и малым объемом данных (до ~10-50к строк).

• Keyset Pagination: Must-have для бесконечных скроллов (infinite scroll), публичных API и таблиц на миллионы записей.

👇 Скинь ссылку на этот пост фронтендеру, который просит «просто добавить номер страницы» в API. А какой метод пагинации чаще всего используете вы в своих текущих проектах? Делитесь в комментариях!

📲 Мы в MAX

#db

👉 @database_info