Индексы в 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

Почему индекс в PostgreSQL не всегда спасает

Индексы - мощный инструмент, но не панацея. Иногда запрос с индексом работает медленнее, чем без него. Почему?

1️⃣ Маленькая выборка - да, полное сканирование - нет
Если таблица маленькая (до нескольких тысяч строк), PostgreSQL может решить, что быстрее прочитать всё целиком, чем прыгать по индексу.

EXPLAIN ANALYZE
SELECT * FROM users WHERE status = 'active';

План покажет Seq Scan, и это не баг.

2️⃣ Индекс не помогает с функциями в WHERE
Запрос вида:

SELECT * FROM orders WHERE DATE(created_at) = '2025-08-12';

не использует индекс по created_at. Решение — переписать условие:

WHERE created_at >= '2025-08-12' AND created_at < '2025-08-13'

3️⃣ Селективность
Если по условию отбирается больше ~5–10% строк, индекс становится невыгодным — чтение с диска и так почти сплошное.

4️⃣ Статистика устарела
PostgreSQL выбирает план по статистике. Если она старая - план может быть неэффективным.

ANALYZE table_name;

- и жизнь наладится.

💡 Вывод: Индекс - не магическая кнопка «ускорить». Следи за планами запросов (EXPLAIN), обновляй статистику и оптимизируй условия.

Сохрани, чтобы не наступить на этот грабельный индекс 🚀

📲 Мы в MAX

#db

👉 @database_info

5 нормальных форм баз данных, которые должен знать каждый разработчик

📲 Мы в MAX

#db

👉 @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

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

📲 Мы в MAX

#db

👉 @database_info

🚨 Антипаттерн: хранить пароли в базе "как есть"

Да, звучит как очевидный совет, но на практике до сих пор встречаются проекты, где пароль сохраняется в чистом виде или максимум в MD5(). Это огромная брешь в безопасности: одна утечка = полный доступ злоумышленника.

🔑 Как правильно:

1. Никогда не храните пароль в открытом виде.

2. Используйте алгоритмы адаптивного хэширования:
– bcrypt
– scrypt
– Argon2 (считается современным стандартом).

3. Настраивайте "cost factor" (число итераций), чтобы усложнить брутфорс.

4. Добавляйте "соль" (salt) к каждому паролю. Обычно библиотеки делают это автоматически.

5. Для дополнительной защиты можно применять pepper — секрет, хранящийся вне БД (например, в конфиге или KMS).

❌ Плохой пример:

INSERT INTO users (login, password) VALUES ('admin', MD5('123456'));

✅ Хороший пример (псевдокод):

hashed = bcrypt.hashpw(password, bcrypt.gensalt())
store_in_db(user, hashed)

💡 Итог: база данных не должна "знать" пароли пользователей. Она должна хранить только безопасные хэши.

Сохрани пост, чтобы потом показать тем, кто всё ещё пишет MD5(password) 😉

📲 Мы в MAX

#db

👉 @database_info

🔥 Индексы в PostgreSQL: когда они реально помогают, а когда мешают

Многие ставят индексы “на всё подряд”, а потом удивляются, почему БД тормозит.

❌ Типичные ошибки:

- Индекс на колонке, которая почти всегда уникальна (например, id с PK — он уже индексирован).
- Индекс на поле с низкой селективностью (is_active = true/false) — толку ноль, только замедляет вставки.
- Создание 5+ индексов на таблицу без анализа запросов.

✅ Best practices:

- Делайте индекс под конкретный частый запрос.
- Для WHERE field LIKE 'abc%' — используйте btree.
- Для поиска по JSONB → GIN индекс.
- Для геоданных → GiST.
- Для частого условия — partial index:

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

⚡️ Помните: каждый индекс ускоряет SELECT, но замедляет INSERT/UPDATE/DELETE.

👉 Итог: индекс — это инструмент, а не магическая таблетка. Всегда проверяйте план выполнения (EXPLAIN ANALYZE).

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

📲 Мы в 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

🚀 Подборка полезных IT каналов в Max


Системное администрирование, DevOps 📌

https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.

1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С

Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика

Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика

Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика

GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных

Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков

Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов

Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻

Шутки программистов 📌
https://max.ru/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free

Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров

Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике

Вакансии 📌
https://max.ru/progjob Вакансии в IT

Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных


Бонус 📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы