Минусы индексов (PostgreSQL):

Тестирование баз данных

1. Занимают место на диске

· Каждый индекс — это отдельная структура данных, которая хранит копии значений ключей и ссылки на строки. · Размер зависит от типа (B-tree, GIN, GiST и т.д.) и количества столбцов.

1. Замедляют операции записи

· INSERT — нужно вставить запись во все индексы таблицы. · UPDATE — если меняется индексируемое поле, происходит удаление старой записи из индекса и вставка новой. В PostgreSQL это фактически пометка старой версии + новая версия (из-за MVCC). · DELETE — удаление записи из индекса. · Поэтому каждая лишняя «копия» индекса (дублирующий, редко используемый) напрямую бьёт по скорости записи.

1. Требуют обслуживания (VACUUM, ANALYZE)

· Индексы тоже накапливают «мёртвые» кортежи после UPDATE/DELETE. VACUUM чистит их внутри индекса (часто это делает autovacuum). · ANALYZE собирает статистику для планировщика; без неё планировщик может выбрать плохой план даже с хорошим индексом. · Если autovacuum не справляется с нагрузкой, индексы раздуваются и начинают деградировать.

1. Со временем могут фрагментироваться (деградация)

· Частые вставки/удаления могут приводить к фрагментации B-tree: страницы индекса становятся полупустыми, растёт количество уровней в глубину, увеличивается количество операций ввода-вывода. · Проявляется как снижение производительности чтения при том же объёме данных. · Лечится REINDEX / VACUUM FULL / pg_repack (для минимизации блокировок).

1. Плохой индекс может ухудшить план запроса

· Если индекс создан на колонке с низкой селективностью (например, пол типа boolean, где 50/50), планировщик может всё равно выбрать Seq Scan, а сам индекс будет только зря занимать место и замедлять запись. · Хуже того: при ошибке в статистике или специфическом распределении данных планировщик иногда может ошибочно предпочесть индексное сканирование, что приведёт к огромному числу случайных обращений к диску и резкому падению производительности. · Планировщик также может недооценить стоимость чтения по индексу — тогда вместо быстрого Seq Scan он начнёт делать много операций random I/O.

Важное дополнение, чтобы пост был завершённым: Бояться индексов не надо, их нужно правильно проектировать и следить за ними. Основные правила:

· Добавлять индексы под конкретные запросы. · Избегать дублирующих индексов (например, (a) и (a, b) — первый часто избыточен). · Следить за статистикой и размером индексов (pg_stat_user_indexes, pgstattuple). · При росте фрагментации планировать REINDEX CONCURRENTLY.