Что такое уровни изоляции в БД?

Уровни изоляции транзакций в базах данных

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

Проблемы параллельного доступа

Прежде чем рассматривать уровни изоляции, нужно понять проблемы, которые они призваны решить:

1. Грязное чтение (Dirty Read): Транзакция читает данные, которые были изменены другой, ещё незавершённой транзакцией. Если та транзакция откатится, прочитанные данные окажутся недействительными.

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

3. Фантомное чтение (Phantom Read): Похоже на неповторяющееся чтение, но касается набора строк. Транзакция дважды выполняет запрос с одним и тем же условием и получает разное количество строк, потому что другая транзакция добавила или удалила строки, удовлетворяющие условию, между этими запросами.

Четыре стандартных уровня изоляции (по ANSI SQL)

Стандарт SQL определяет четыре уровня изоляции, которые можно представить как лестницу: чем выше уровень, тем строже изоляция и тем меньше аномалий допускается, но за это приходится платить производительностью из-за более интенсивного использования блокировок.

1. Read Uncommitted (Чтение незафиксированных данных)

Самый низкий уровень. Транзакция может видеть незафиксированные изменения других транзакций (т.е. "грязные" данные).

• Разрешает: Грязное чтение, Неповторяющееся чтение, Фантомное чтение.
• Использование: Крайне редко, в сценариях, где важна только максимальная скорость, а согласованность данных критически не важна (например, агрегированная аналитика по историческим данным).
• Как реализуется: Обычно чтение без каких-либо блокировок.

2. Read Committed (Чтение зафиксированных данных)

Самый распространённый уровень по умолчанию во многих СУБД (PostgreSQL, SQL Server, Oracle). Транзакция видит только данные, зафиксированные другими транзакциями на момент начала её операции чтения (не момента начала всей транзакции!).

• Запрещает: Грязное чтение.
• Разрешает: Неповторяющееся чтение, Фантомное чтение.
• Использование: Баланс между производительностью и согласованностью. Подходит для большинства OLTP-приложений.
• Реализация в SQL Server / PostgreSQL (пример):

  -- Установка уровня изоляции для сессии
  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  BEGIN TRANSACTION;
  -- Эта выборка увидит только зафиксированные данные.
  -- Если между двумя вызовами этого SELECT другая транзакция изменит и зафиксирует строку, 
  -- второй вызов вернёт новое значение (неповторяющееся чтение).
  SELECT Balance FROM Accounts WHERE Id = 1;
  -- ... какая-то работа ...
  SELECT Balance FROM Accounts WHERE Id = 1; -- Может вернуть другое значение!
  COMMIT;
  

3. Repeatable Read (Повторяемое чтение)

Гарантирует, что данные, прочитанные один раз в рамках транзакции, не изменятся другими транзакциями до её завершения.

• Запрещает: Грязное чтение, Неповторяющееся чтение.
• Разрешает: Фантомное чтение (в некоторых СУБД, например, PostgreSQL, этот уровень также предотвращает фантомы за счёт механизма snapshot).
• Использование: Когда критически важно, чтобы набор прочитанных данных оставался неизменным на протяжении всей бизнес-логики транзакции (например, проверка остатков перед списанием).
• Реализация в MySQL / SQL Server:

  SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
  START TRANSACTION;
  SELECT * FROM Orders WHERE Status = 'Pending'; -- Снимок данных
  -- Даже если другая транзакция изменит существующие строки с Status='Pending' и зафиксируется здесь,
  -- этот SELECT внутри нашей транзакции всё равно вернёт старые значения.
  -- Однако, если будет вставлена НОВАЯ строка с Status='Pending', она может "пропасть" (фантом).
  COMMIT;
  

4. Serializable (Сериализуемый)

Самый строгий уровень. Имитирует последовательное (serial) выполнение транзакций, как если бы они выполнялись одна за другой. Полностью предотвращает все три аномалии.

• Запрещает: Грязное чтение, Неповторяющееся чтение, Фантомное чтение.
• Использование: Для операций, требующих абсолютной точности, когда цена ошибки из-за параллелизма очень высока (финансовые операции, распределение уникальных ресурсов). Значительно снижает производительность.
• Реализация: Часто использует блокировки диапазона ключей или оптимистичный контроль параллелизма на основе версий (snapshot isolation).

  // Пример на C# с Entity Framework Core (используется атрибут)
  using (var context = new AppDbContext())
  {
      using (var transaction = context.Database.BeginTransaction(System.Data.IsolationLevel.Serializable))
      {
          try
          {
              var total = context.Orders.Where(o => o.Date == today).Sum(o => o.Amount);
              // На время этой транзакции другие транзакции не могут вставлять,
              // изменять или удалять строки в Orders, которые могли бы повлиять на результат этого запроса.
              if (total < dailyLimit)
              {
                  context.Orders.Add(newOrder);
                  context.SaveChanges();
              }
              transaction.Commit();
          }
          catch
          {
              transaction.Rollback();
          }
      }
  }
  

Snapshot Isolation (Изоляция моментального снимка)

Это расширенный уровень, не описанный в стандарте ANSI, но реализованный в SQL Server (READ_COMMITTED_SNAPSHOT, SNAPSHOT), PostgreSQL (REPEATABLE READ, SERIALIZABLE через MVCC) и Oracle. Его суть — версионирование данных. Каждая транзакция работает со своим согласованным снимком данных на момент её начала. Чтения не блокируют записи, а записи не блокируют чтения. Это позволяет избегать многих блокировок, повышая производительность при высокой конкуренции на чтение. Аномалия «запись-после-чтения» предотвращается на уровне SNAPSHOT при обнаружении конфликта параллельных изменений.

Практические рекомендации для C# Backend-разработчика

• Не используйте уровень по умолчанию, не понимая его. Изучите, что используется в вашем проекте (Read Committed или Read Committed Snapshot).
• Повышайте уровень изоляции осознанно. Начинайте с Read Committed и повышайте только для конкретных, критичных операций, оборачивая их в явную транзакцию с нужным уровнем.
• Снижайте время жизни транзакции. Чем дольше транзакция, особенно на высоких уровнях изоляции, тем выше шанс конфликтов и взаимных блокировок (deadlock).
• Помните о компромиссе. Более строгая изоляция = меньше параллелизма и потенциально ниже производительность.
• Используйте паттерны оптимистичного контроля параллелизма (например, проверку версии строки в WHERE-условии при обновлении) как альтернативу строгой изоляции для сценариев «последний выигрывает» или «первый выигрывает».

Выбор правильного уровня изоляции — это поиск баланса между требованиями к целостности данных, производительностью и сложностью реализации конкретного бизнес-процесса.