- Для первичного ключа индекс создается автоматически
- Профиль нагрузки на реляционную базу данных выглядит следующим образом: 80% запросов это чтение, 20% запросов это запись. Если запросов на запись больше, то возможно реляционная база данных вам не подходит.
- Плюсы индексов
- Ускорение запросов
- Минусы
- Замедление записи в таблицы (80% к 20%). Так как необходимо будет перестраивать индекс при вставке новых значений.
- Дополнительные объемы дискового пространства. Размер индекса в половину размера таблицы считается нормальным и оптимальным
- Усложненное технического обслуживание.
-#todo bloat. индексы пухнуть и переодически их нужно пересоздавать
- Перед созданием индекса стоит провести предварительный анализ. Так как не все индексы полезны, некоторые индексы могут ухудшить ситуацию.
- **Что нужно для создания индекса?**
- Ориентироваться только на продуктовое окружение, так как тестовые окружения не соответствуют реальности.
- pgBadger - использовать с осторожностью. Собирает статистику из логов postgres. Но в логи попадают не все запросы.
- Иметь примеры запросов с параметрами.
- Для понимания входящих параметров запроса.
- Необходимо для проверки оптимизаций
- Уметь читать статистику распределения данных (планировщик).
- Представление [pg_stats](Таблица%20статистик%20pg_stats.md).
- Вручную собрать более полную статистику.
- По умолчанию PostgrteSQL использует для сбора статистики только 30k строк из таблицы. Из-за этого статистика может расходиться с реальностью.
- **Типы индексов**
- btree
- Наиболее распространенный тип индексов
- Очень хороший алгоритм работы
- Покрывает 90% задач
- Легко создать ориентируясь на статистику по таблице
- Обслуживает как операции сравнения так и операции равенства
- Позволяет выполнить сортировку
- hash индекс
- Абсолютно бесполезен. Используйте btree.
- Занимает меньше места на диске, чем btree
- Обслуживает только операции равенства.
- Нельзя выполнить сортировку
- gist индекс
-В чистом виде полезен для гео-данных
- Расширения
- pg_trgm - like, ilike, ~, ~* (regexp)
- btree_gits - слодные constrains с интервалами. Позволяет переложить на базу данных задачу по контролю пересечения времени. Например, если нужно создать расписание, и чтобы временные интервалы заданий не пересекались.
- sp_gist индекс
- Нет практических применений в [OLTP](OLTP.md)
- Возможно полезен в научной сфере
- gin индекс
- Может сильно ухудшить время вставки в таблицу
- Хорошо для текстового поиска
- Позволяет ускорить поиск по jsonb
- jsonb_ops - используется по умолчанию. Индексирует все значения jsonb, из-за этого индекс получается больших размеров.
- json_path_ops - заточен на поиск путей в json. То есть позволяет ответить, есть ли такое-то поле в jsonb или его нет.
- brin
- Компактный индекс
- Подходит для упорядоченных данных
## Практика
![](Pasted%20image%2020240331092706.png)
![](Pasted%20image%2020240331092753.png)
- Индекс по первичному ключу занял 1/4 от размера таблицы
- Таблица ссылается сама на себя, но это сделано для удобства доклада. Те же самые выводы распространятся и на связи с другими таблицами.
### Удаляем строку
![600](Pasted%20image%2020240331093028.png)
-В удалении задействован первичный ключ, поэтому используется поиск по индексу
- ==Самый долгий этап это проверка связей с таблицей==
Под капотом для поиска внешних связей мы используем полное сканирование таблицы (Seq Scan).