> Приходилось ли менять уровни изоляции транзакций? (Go)

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

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

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

Уровни изоляции транзакций - это компромисс между консистентностью данных и производительностью. В Go с PostgreSQL через database/sql или pgx управление уровнями изоляции происходит на уровне SQL-запросов или параметров подключения.

Основные сценарии, когда приходилось менять:

1. READ COMMITTED → REPEATABLE READ - когда в рамках одной транзакции выполнялось несколько запросов, и нужно было гарантировать, что данные не изменятся между ними (например, чтение баланса и последующее списание).

2. REPEATABLE READ → SERIALIZABLE - для критических операций с высоким риском гонок (например, бронирование последнего места или уникальные ограничения, которые нельзя выразить через индексы).

3. READ UNCOMMITTED - практически не использовал, так как в PostgreSQL он не поддерживается (маппится на READ COMMITTED), а в MySQL даёт грязные чтения.

Важно понимать, что в Go нет прямого API для управления изоляцией - всё сводится к выполнению SET TRANSACTION ISOLATION LEVEL ... перед началом транзакции или указанию уровня в BEGIN.

На практике

В реальных проектах чаще всего достаточно дефолтного READ COMMITTED. Менял уровень только когда:

• появлялись баги с некорректными данными при конкурентных операциях (например, двойное списание средств);
• требовалось выполнить сложный расчёт с несколькими чтениями, где промежуточные изменения других транзакций ломали логику;
• возникали проблемы с уникальностью данных, которые нельзя было решить через UNIQUE-индексы.

Также важно помнить про SELECT ... FOR UPDATE - это альтернатива повышению уровня изоляции, которая блокирует строки явно и часто более предсказуема по поведению.

Пример кода

GO
package main

import (
    "context"
    "github.com/jackc/pgx/v5"
)

func updateBalance(ctx context.Context, conn *pgx.Conn, userID int, amount int64) error {
    tx, err := conn.BeginTx(ctx, pgx.TxOptions{
        IsoLevel: pgx.RepeatableRead,
    })
    if err != nil {
        return err
    }
    defer tx.Rollback(ctx)

    // Читаем баланс
    var balance int64
    err = tx.QueryRow(ctx,
        "SELECT balance FROM accounts WHERE user_id = $1 FOR UPDATE",
        userID,
    ).Scan(&balance)
    if err != nil {
        return err
    }

    // Проверяем и обновляем
    if balance+amount < 0 {
        return fmt.Errorf("insufficient funds")
    }
    _, err = tx.Exec(ctx,
        "UPDATE accounts SET balance = balance + $1 WHERE user_id = $2",
        amount, userID,
    )
    if err != nil {
        return err
    }

    return tx.Commit(ctx)
}

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

Начните с конкретного примера из практики: опишите проблему, которую решали, и почему выбрали именно этот уровень. Затем объясните trade-off: что выиграли и что потеряли. Покажите понимание аномалий (dirty read, non-repeatable read, phantom read) и как уровень изоляции влияет на каждую из них. Упомяните, что в PostgreSQL SERIALIZABLE реализован через SSI (Serializable Snapshot Isolation) и имеет свои особенности с ошибками сериализации.

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

• Понимание теории транзакций и аномалий чтения.
• Практический опыт: не просто знание определений, а умение применить в реальной задаче.
• Осознание trade-off между консистентностью и производительностью.
• Знание особенностей конкретной СУБД (PostgreSQL, MySQL) и их реализации уровней изоляции.
• Умение объяснить, когда повышение уровня изоляции - не лучшее решение, и какие есть альтернативы (locking, optimistic concurrency).

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

• Ответ без конкретного примера - только теория.
• Утверждение, что SERIALIZABLE решает все проблемы - на деле он часто даёт ошибки сериализации и требует retry-логики.
• Путаница между уровнями изоляции и блокировками - это разные механизмы, хотя и связанные.
• Игнорирование особенностей СУБД: например, в MySQL REPEATABLE READ - дефолт, а в PostgreSQL - READ COMMITTED.
• Забывают про FOR UPDATE как альтернативу повышению уровня изоляции.