Какой самый жесткий уровень изоляции?

Уровень изоляции транзакций в SQL

Самый жесткий (или строгий) уровень изоляции транзакций в большинстве систем управления реляционными базами данных (СУБД), таких как PostgreSQL, MySQL, SQL Server, - это уровень SERIALIZABLE. Этот уровень обеспечивает максимальную защиту от всех классических аномалий параллельного выполнения транзакций, гарантируя, что результат выполнения набора параллельных транзакций будет идентичен результату их последовательного (serial) выполнения.

Почему SERIALIZABLE считается самым жестким?

Стандарт SQL определяет четыре уровня изоляции, направленные на предотвращение трех ключевых аномалий:

1. Dirty Read (Чтение "грязных" данных) - чтение незафиксированных изменений другой транзакции.
2. Non-repeatable Read (Неповторяющееся чтение) - изменение значения строки, прочитанной ранее в той же транзакции.
3. Phantom Read (Чтение "фантомов") - появление новых строк в результате повторного выполнения запроса с теми же условиями.

Уровень SERIALIZABLE предотвращает все три аномалии. Он гарантирует, что ни одна из транзакций не сможет увидеть эффекты других параллельных транзакций так, как будто они выполнялись в каком-то произвольном, несериализуемом порядке.

Как реализуется уровень SERIALIZABLE?

Реализация может различаться в зависимости от СУБД. Существует два основных подхода:

1. Строгое двухфазное блокирование (Pessimistic Locking):

    Транзакции устанавливают блокировки на читаемые и изменяемые данные (например, блокировки диапазонов), что предотвращает их изменение другими транзакциями до завершения. Этот метод может приводить к значительному снижению производительности и увеличению вероятности **взаимоблокировок (deadlocks)**.

1. Управление параллельным доступом на основе многоверсионности с обнаружением конфликтов (Optimistic Concurrency Control - MVCC):

    Этот подход, используемый, например, в PostgreSQL начиная с версии 9.1, более современный. Он не блокирует данные на запись. Вместо этого система отслеживает зависимости между транзакциями. Если в конце выполнения транзакции обнаруживается, что её результат мог быть бы другим из-за изменений, внесенных другими параллельно завершившимися транзакциями (т.е. нарушена сериализуемость), то такая транзакция **прерывается с ошибкой сериализации**, и её необходимо перезапустить вручную. Это требует от разработчика обработки таких ошибок в прикладном коде.

    **Пример кода обработки сериализуемой транзакции в Go (с использованием `database/sql`):**

```go
package main

import (
    "context"
    "database/sql"
    "errors"
    "fmt"
    "log"

    // Драйвер для PostgreSQL
    _ "github.com/lib/pq"
)

func transferFundsSerializable(db *sql.DB, fromID, toID int, amount float64) error {
    // Начинаем транзакцию с уровнем изоляции SERIALIZABLE
    tx, err := db.BeginTx(context.Background(), &sql.TxOptions{
        Isolation: sql.LevelSerializable, // Указываем жесткий уровень изоляции
    })
    if err != nil {
        return err
    }
    // Гарантируем откат в случае неудачи
    defer tx.Rollback()

    // 1. Проверяем баланс отправителя и списываем средства
    var balance float64
    err = tx.QueryRow(`SELECT balance FROM accounts WHERE id = $1 FOR UPDATE`, fromID).Scan(&balance)
    if err != nil {
        return err
    }
    if balance < amount {
        return errors.New("insufficient funds")
    }
    _, err = tx.Exec(`UPDATE accounts SET balance = balance - $1 WHERE id = $2`, amount, fromID)
    if err != nil {
        return err
    }

    // 2. Зачисляем средства получателю
    _, err = tx.Exec(`UPDATE accounts SET balance = balance + $1 WHERE id = $2`, amount, toID)
    if err != nil {
        return err
    }

    // Попытка фиксации. Здесь может произойти ошибка сериализации.
    err = tx.Commit()
    if err != nil {
        // Проверяем, является ли ошибка ошибкой сериализации (код 40001 в PostgreSQL)
        // или ошибкой взаимоблокировки (код 40P01).
        // В реальном приложении эту проверку нужно делать через драйвер/библиотеку.
        if err.Error() == "pq: could not serialize access due to concurrent update" {
            // Логируем и возвращаем ошибку, которую вызывающий код должен обработать,
            // например, повторно запустив всю операцию.
            log.Println("Serialization failure, transaction should be retried")
            return err // Вызывающая функция должна перезапустить транзакцию
        }
        return err
    }
    return nil
}

func main() {
    // Инициализация соединения с БД
    db, err := sql.Open("postgres", "postgres://...")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    // Повторяем операцию несколько раз в случае ошибки сериализации
    for i := 0; i < 5; i++ {
        err = transferFundsSerializable(db, 1, 2, 100.0)
        if err == nil {
            fmt.Println("Transfer successful")
            break
        }
        if err.Error() == "pq: could not serialize access due to concurrent update" {
            fmt.Printf("Attempt %d failed due to serialization. Retrying...\n", i+1)
            continue
        }
        // Другие ошибки не перезапускаем
        log.Fatal(err)
    }
}
```

Цена жесткой изоляции: производительность vs. корректность

• Надежность данных: SERIALIZABLE обеспечивает максимальную консистентность, что критично для финансовых операций, систем бронирования, аудита, где каждая транзакция должна видеть согласованное состояние данных.
• Производительность: Этот уровень влечет за собой наибольшие накладные расходы:

    *   При **пессимистичном** подходе: высокий риск взаимоблокировок и снижение параллелизма из-за долгих блокировок.
    *   При **оптимистичном** подходе: необходимость перезапуска транзакций, что увеличивает общее время выполнения операций под высокой конкурентной нагрузкой.

Вывод

SERIALIZABLE является самым строгим уровнем изоляции. Его следует выбирать осознанно, только для транзакций, где абсолютная корректность данных приоритетнее максимальной производительности. Для многих других сценариев часто достаточно менее строгих уровней, таких как REPEATABLE READ (в PostgreSQL он также предотвращает фантомные чтения за счет механизма снимков состояния) или READ COMMITTED, которые обеспечивают хороший баланс между целостностью данных и скоростью работы. Ключевая задача разработчика — понимать бизнес-требования к данным и выбирать уровень изоляции, соответствующий этим требованиям.