Что будет если поменять значение в проиндексированном поле?

Отличный вопрос, касающейся механики индексов в БД. Поменять значение в проиндексированном поле — совершенно нормальная операция, и БД сама управляет индексом автоматически.

Что происходит под капотом

Когда я выполняю UPDATE на проиндексированном поле:

UPDATE users SET email = 'newemail@example.com' WHERE id = 123;

База данных сама выполняет следующие шаги:

1. Находит старое значение в индексе — локализует позицию старого email в B-tree индексе
2. Удаляет старую запись из индекса — удаляет связь старого значения с row ID 123
3. Добавляет новую запись в индекс — добавляет связь нового значения с тем же row ID
4. Обновляет сам row — изменяет значение в основной таблице

Это всё происходит атомарно в одной транзакции, поэтому консистентность гарантирована.

Производительность

UPDATE на индексированном поле медленнее чем на неиндексированном:

-- Быстро (обновляем неиндексированное поле)
UPDATE users SET description = 'new desc' WHERE id = 123; -- O(log n) поиск по PK

-- Медленнее (обновляем индексированное поле)
UPDATE users SET email = 'new@email.com' WHERE id = 123; 
-- O(log n) поиск по PK + O(log n) удаление из индекса + O(log n) вставка в индекс

Каждый индекс на обновляемом поле добавляет overhead:

• Для таблицы с 3 индексами на UPDATEе потребуется переиндексировать 3 B-tree структуры

Batch UPDATEы

При обновлении много строк нужно учитывать индексы:

-- Плохо: множественные однострочные UPDATEы
BEGIN;
UPDATE users SET status = 'active' WHERE id = 1;
UPDATE users SET status = 'active' WHERE id = 2;
UPDATE users SET status = 'active' WHERE id = 3;
COMMIT;

-- Хорошо: один batch UPDATE
UPDATE users SET status = 'active' WHERE status = 'pending';

В первом случае индекс перестраивается 3 раза. Во втором — один раз, это значительно эффективнее.

Пример из реальной практики

// Обновляем user по ID (использует PRIMARY KEY индекс)
await pool.query(
  'UPDATE users SET email = $1, updated_at = NOW() WHERE id = $2',
  [newEmail, userId]
);

// Это включает:
// 1. B-tree поиск по id (очень быстро, O(log n))
// 2. Удаление старого email из индекса (O(log n))
// 3. Вставку нового email в индекс (O(log n))
// 4. Обновление row в основной таблице

Особые случаи

Уникальный индекс (UNIQUE constraint):

CREATE UNIQUE INDEX idx_users_email ON users(email);

UPDATE users SET email = 'duplicate@example.com' WHERE id = 1;
-- Если email уже существует — будет ошибка constraint violation
-- БД проверит уникальность ДО выполнения UPDATEа

Составной индекс:

CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);

-- UPDATE на любом из полей обновит индекс
UPDATE orders SET user_id = 456 WHERE id = 789;
UPDATE orders SET created_at = NOW() WHERE id = 789;

Частичный индекс (WHERE clause):

CREATE INDEX idx_active_users ON users(email) WHERE status = 'active';

-- Если поменять статус с 'active' на 'inactive' — 
-- запись удалится из этого индекса (т.к. больше не выполняет WHERE условие)
UPDATE users SET status = 'inactive' WHERE id = 123;

Оптимизация

Если UPDATE на индексированном поле критичен по производительности:

1. Рассмотреть удаление индекса если поле редко используется в WHERE условиях (нет профита от чтения)
2. Использовать PARTIAL INDEX только для часто обновляемого подмножества
3. Кластеризованный индекс — если часто сортируешь/фильтруешь по этому полю, оно стоит оптимизации
4. ANALYZE и VACUUM после массовых UPDATEов — база пересчитает статистику, оптимизатор выберет лучший план

-- После batch UPDATE
VACUUM ANALYZE users;

Заключение

Обновлять индексированные поля — нормально и безопасно. БД сама управляет консистентностью. Главное помнить, что UPDATE на индексированном поле медленнее неиндексированного на величину O(k*log n), где k — количество индексов на поле. Для критичных по производительности операций нужно это учитывать при проектировании схемы.