В какую таблицу будет дольше вставляться элемент: с индексами или без индексов

Влияние индексов на INSERT операции

Быстрый ответ

Вставка в таблицу С индексами будет МЕДЛЕННЕЕ, чем без индексов. За эту производительность приходится платить при записи данных.

Почему индексы замедляют INSERT

Это часто удивляет начинающих разработчиков, но логика проста:

1. Дополнительная работа при вставке

Когда вставляется новая строка в таблицу:

• БЕЗ индексов: просто добавляем строку в конец таблицы (очень быстро)
• С индексами: нужно обновить ВСЕ индексы, связанные с этой таблицей

Для каждого индекса нужно:

1. Вычислить значение индексного поля
2. Найти правильное место в B-tree структуре индекса
3. Вставить новое значение в индекс
4. Перебалансировать B-tree если нужно

2. Пример с числами

Таблица users с 1 млн строк

Сценарий 1: БЕЗ индексов
INSERT занимает: 0.5ms

Сценарий 2: С 5 индексами (id, email, username, created_at, status)
INSERT занимает: 2-3ms

Разница: в 4-6 раз медленнее!

Практический пример на Java

// Без индексов - чистое добавление
public void insertUserNoIndexes(User user) {
    // INSERT INTO users (id, name, email, phone, address) VALUES (?, ?, ?, ?, ?)
    // Просто добавляем строку в конец таблицы
    // Время: O(1) - константное
}

// С индексами - обновляем все индексы
public void insertUserWithIndexes(User user) {
    // Кроме самой вставки, база должна:
    // 1. Обновить индекс по id (PRIMARY KEY)
    // 2. Обновить индекс по email (UNIQUE INDEX)
    // 3. Обновить индекс по username (INDEX)
    // 4. Обновить индекс по created_at (INDEX)
    // 
    // Время: O(log N) для каждого индекса, итого: O(k * log N)
    // где k = количество индексов, N = количество строк
}

Компромисс: Select vs Insert

Однако индексы нужны не зря - они ускоряют SELECT операции:

// БЕЗ индекса на email - полное сканирование таблицы
// SELECT * FROM users WHERE email = ?
// Время: O(N) - линейное от количества строк

// С индексом на email
// SELECT * FROM users WHERE email = ?
// Время: O(log N) - логарифмическое

Таблица компромиссов

Операция      | БЕЗ индексов | С индексами | Выигрыш/Проигрыш
-----------------------------------------------------------------
INSERT        | O(1)         | O(k*log N)  | ❌ Медленнее в k раз
UPDATE (поле) | O(N)         | O(log N)    | ✅ Быстрее в N раз
DELETE        | O(N)         | O(log N)    | ✅ Быстрее в N раз
SELECT (где)  | O(N)         | O(log N)    | ✅ Быстрее в N раз
SELECT (all)  | O(N)         | O(N)        | Одинаково

Когда оптимизировать INSERT

Bulk Insert (вставка большого количества данных)

// Неоптимально - для каждого INSERT обновляются все индексы
List<User> users = loadMillion();
for (User user : users) {
    insertUser(user);  // 1M INSERT'ов = обновление индексов 1M раз
}
// Время: ~1000ms

// Оптимально - отключаем индексы перед вставкой
public void bulkInsertUsers(List<User> users) {
    database.execute("ALTER TABLE users DISABLE KEYS");
    try {
        for (User user : users) {
            insertUser(user);
        }
    } finally {
        database.execute("ALTER TABLE users ENABLE KEYS");
        // БД пересчитает индексы один раз
    }
    // Время: ~50ms
}

Или через JDBC batch:

PreparedStatement pstmt = conn.prepareStatement(
    "INSERT INTO users (id, name, email) VALUES (?, ?, ?)"
);

for (User user : users) {
    pstmt.setLong(1, user.getId());
    pstmt.setString(2, user.getName());
    pstmt.setString(3, user.getEmail());
    pstmt.addBatch();
}

pstmt.executeBatch();  // Выполняет все одной операцией

Правило большого пальца

1. Много INSERT'ов, мало SELECT'ов → Меньше индексов или отключай их во время bulk insert
2. Много SELECT'ов, мало INSERT'ов → Много индексов
3. Сбалансированная нагрузка → Выбирай индексы по запросам через EXPLAIN ANALYZE

Правильная стратегия

// ПЛОХО - добавляет индекс для каждого поля
@Entity
public class User {
    @Id
    @Indexed
    private Long id;
    
    @Indexed  // ненужный индекс если редко ищешь по имени
    private String name;
    
    @Indexed  // имеет смысл
    private String email;
    
    @Indexed  // ненужный индекс
    private LocalDateTime createdAt;
}

// ХОРОШО - индексы на часто используемые поля в WHERE
@Entity
public class User {
    @Id
    private Long id;  // автоматически индексирован
    
    private String name;
    
    @Indexed  // часто ищут по email
    private String email;
    
    @Indexed  // часто фильтруют по дате
    private LocalDateTime createdAt;
}

Вывод

Да, таблица с индексами будет вставляться медленнее (в 2-5 раз в зависимости от количества индексов). Но это справедливая плата за огромное ускорение SELECT операций. Правильно выбирай индексы на основе реальных query паттернов, а не добавляй их "на всякий случай".