> Влияют ли индексы на другие запросы кроме ускорения поиска (Go)

Короткий ответ

Да, индексы влияют на все операции с таблицей: SELECT, INSERT, UPDATE, DELETE. Они ускоряют поиск, но добавляют overhead на запись, увеличивают размер хранилища и могут менять план выполнения запросов. В PostgreSQL и MySQL индексы также влияют на блокировки, порядок сканирования и использование памяти. Иногда индекс может замедлить запрос, если оптимизатор выбирает неэффективный plan. Поэтому индексы - это trade-off между read и write производительностью.

Подробное объяснение

Индексы - это структуры данных, которые ускоряют поиск строк, но их влияние выходит далеко за рамки простого ускорения SELECT. Рассмотрим основные эффекты:

Влияние на запись (INSERT/UPDATE/DELETE)
Каждый индекс требует обновления при изменении данных. При INSERT добавляется новая запись в каждый индекс. При UPDATE - если изменяется индексируемая колонка, происходит delete + insert в индексе. При DELETE - удаление из всех индексов. Это увеличивает latency операций записи и создает дополнительную нагрузку на WAL (write-ahead log) в PostgreSQL.

Влияние на план выполнения
Оптимизатор может выбрать index scan вместо sequential scan, но это не всегда быстрее. Для маленьких таблиц sequential scan часто эффективнее - индекс добавляет дополнительные I/O. Также индекс может быть проигнорирован, если селективность низкая (например, колонка с boolean).

Влияние на блокировки
При вставке в таблицу с индексами блокируются не только страницы таблицы, но и страницы индексов. Это увеличивает вероятность deadlock и contention при конкурентной записи. В PostgreSQL используется heap-only tuple update для оптимизации, но при обновлении индексируемых колонок это не работает.

Влияние на память и кэш
Индексы занимают место в shared_buffers (PostgreSQL) или buffer pool (MySQL). Большой индекс может вытеснять из кэша горячие страницы таблицы, замедляя другие запросы.

Влияние на сортировку и группировку
Индекс может использоваться для ORDER BY и GROUP BY, избегая отдельной сортировки. Но если индекс не покрывает запрос полностью, может потребоваться дополнительная сортировка в памяти или на диске.

Влияние на JOIN
Индексы на колонках JOIN ускоряют соединение, но также могут изменить выбор метода соединения - nested loop вместо hash join. Это может быть как плюсом, так и минусом.

Влияние на вакуум (PostgreSQL)
Индексы увеличивают работу autovacuum, так как требуется обновление visibility map и зачистка dead tuples в индексах.

На практике

При проектировании индексов важно учитывать не только read-паттерны, но и write-нагрузку. Основные практические рекомендации:

• Измеряйте write-стоимость - для high-write систем каждый лишний индекс может быть критичен. Например, в системах с event sourcing или логами.
• Используйте покрывающие индексы - они позволяют избежать table lookup, но увеличивают размер индекса.
• Следите за bloat - в PostgreSQL индексы могут раздуваться из-за обновлений, что требует REINDEX.
• Тестируйте с реальными данными - оптимизатор принимает решения на основе статистики, которая может отличаться на тестовых данных.
• Используйте partial indexes - они индексируют только часть строк, уменьшая overhead на запись.
• Мониторьте index usage - в PostgreSQL можно посмотреть pg_stat_user_indexes, чтобы найти неиспользуемые индексы.

Пример из практики: в системе с 1000 writes/sec добавление одного индекса на таблицу с 10 млн строк увеличило p99 latency записи с 5ms до 12ms. При этом SELECT ускорился с 200ms до 2ms. Вопрос - стоит ли trade-off, зависит от соотношения read/write.

Пример кода

GO
// Пример влияния индекса на write latency в PostgreSQL через Go

func insertWithIndex(db *sql.DB, rows int) time.Duration {
    start := time.Now()
    for i := 0; i < rows; i++ {
        _, err := db.Exec(
            "INSERT INTO users (email, name) VALUES ($1, $2)",
            fmt.Sprintf("user%d@example.com", i),
            fmt.Sprintf("User %d", i),
        )
        if err != nil {
            panic(err)
        }
    }
    return time.Since(start)
}

// Проверка использования индекса
func checkIndexUsage(db *sql.DB) {
    rows, _ := db.Query(`
        SELECT relname, idx_scan, idx_tup_read
        FROM pg_stat_user_indexes
        WHERE relname = 'users'
    `)
    defer rows.Close()
    for rows.Next() {
        var relname string
        var idxScan, idxTupRead int64
        rows.Scan(&relname, &idxScan, &idxTupRead)
        log.Printf("Index on %s: scans=%d, tuples=%d", relname, idxScan, idxTupRead)
    }
}

Как отвечать на собеседовании

Начните с прямого ответа: "Да, индексы влияют на все операции, не только на чтение". Затем структурируйте ответ по категориям: запись, план выполнения, блокировки, память. Приведите конкретный пример trade-off. Покажите, что понимаете внутренности - упомяните heap-only tuple update, bloat, статистику оптимизатора. Если спросят про Go - свяжите с реальным опытом: как вы измеряли latency, какие метрики смотрели. Не углубляйтесь в теорию без практики - интервьюер ждет, что вы решали такие проблемы в продакшене.

Что проверяет интервьюер

Интервьюер оценивает:

• Глубину понимания - знаете ли вы, что индекс - это не бесплатное ускорение, а структура с cost.
• Системное мышление - видите ли вы влияние на блокировки, память, вакуум.
• Практический опыт - можете ли вы привести реальный кейс, когда индекс навредил.
• Умение делать trade-off - понимаете ли вы, как балансировать между read и write.
• Знание конкретной СУБД - в вопросе указан Go, но важно показать знание PostgreSQL или MySQL.

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

• Ответ "индексы только ускоряют SELECT" - сразу показывает поверхностное понимание.
• Игнорирование write-стоимости - кандидат не упоминает INSERT/UPDATE/DELETE.
• Утверждение, что индекс всегда ускоряет - не учитывает селективность и размер таблицы.
• Непонимание bloat и вакуума - для senior это критично.
• Отсутствие конкретики - общие слова без цифр и примеров.
• Путаница между кластерным и некластерным индексом - в PostgreSQL нет кластерных индексов в смысле MySQL, это важно понимать.
• Игнорирование влияния на JOIN и ORDER BY - индекс может менять план выполнения неочевидным образом.