Какой уровень изоляции выбрать для таблицы пользователей, где каждый пользователь может изменять только свою строку, а администратор - менять любые данные?

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

Для сценария, где каждый пользователь может изменять только свою строку, а администратор — любые данные, рекомендуется использовать READ COMMITTED как оптимальный баланс между безопасностью и производительностью. Однако в зависимости от требований безопасности можно рассмотреть и другие уровни.

Иерархия уровней изоляции SQL

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

READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE
↓ Риск проблем      ↓ Параллелизм ↓ Производительность ↑

1. READ UNCOMMITTED (грязное чтение)

Характеристики:

• Позволяет читать незафиксированные данные ("грязное чтение")
• Самый быстрый уровень
• Может привести к инкорректным данным

public class DirtyReadExample {
    // Transaction 1: Добавляет 1000 к балансу
    // UPDATE accounts SET balance = balance + 1000 WHERE id = 1;
    
    // Transaction 2 (READ UNCOMMITTED): Читает незафиксированное значение
    // SELECT balance FROM accounts WHERE id = 1; // Видит временное значение
    
    // Transaction 1: Откатывается (ROLLBACK)
    // Значение, прочитанное Transaction 2, больше не существует (грязное чтение)
}

❌ НЕ рекомендуется для таблицы пользователей — слишком опасно.

2. READ COMMITTED (избегает грязного чтения)

Характеристики:

• Не читает незафиксированные данные
• Может видеть обновления, совершённые другими транзакциями
• Хороший баланс между безопасностью и производительностью
• По умолчанию в PostgreSQL

public class ReadCommittedExample {
    // Transaction 1
    public void updateUserEmail(Long userId, String newEmail) {
        String sql = "UPDATE users SET email = ? WHERE id = ?";
        jdbcTemplate.update(sql, newEmail, userId);
        // Другие транзакции видят это обновление только после COMMIT
    }
    
    // Transaction 2
    public User getUserData(Long userId) {
        // Видит только зафиксированные данные
        String sql = "SELECT * FROM users WHERE id = ?";
        return jdbcTemplate.queryForObject(sql, new UserRowMapper(), userId);
    }
}

Проблема: Non-repeatable read

// Transaction A читает данные дважды
User user1stRead = readUser(1); // age = 25
// [В это время Transaction B меняет age на 26]
User user2ndRead = readUser(1); // age = 26 (другое значение!)

✅ Рекомендуется для таблицы пользователей — обычно достаточно.

3. REPEATABLE READ (избегает non-repeatable read)

Характеристики:

• Каждое прочитанное значение остаётся неизменным в рамках одной транзакции
• Может видеть новые строки, добавленные другими транзакциями (phantom read)
• Использует снимки данных (MVCC в PostgreSQL)
• По умолчанию в MySQL

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void updateUserProfile(Long userId) {
    // Первое чтение
    User user1 = getUser(userId); // age = 25
    
    // Даже если другая транзакция изменит эту строку...
    // Мы видим ту же версию данных
    User user2 = getUser(userId); // age = 25 (тот же снимок)
    
    // Но видим новые добавленные строки
    List<User> allUsers = getAllUsers(); // Может содержать новых пользователей
}

Проблема: Phantom read

// Transaction A
int count1 = countUsersWithAge(25); // Возвращает 5
// [Transaction B добавляет нового пользователя с age = 25]
int count2 = countUsersWithAge(25); // Возвращает 6 (phantom read)

✅ Можно использовать если нужна гарантия повторяемости чтения.

4. SERIALIZABLE (полная изоляция)

Характеристики:

• Полная изоляция между транзакциями
• Транзакции выполняются так, как будто одна за другой
• Медленнейший уровень, высокий риск deadlock'ов
• Избегает всех проблем: грязные чтения, non-repeatable reads, phantom reads

@Transactional(isolation = Isolation.SERIALIZABLE)
public void criticalBankTransfer(Long fromAccount, Long toAccount, BigDecimal amount) {
    // Полная защита от всех аномалий
    BigDecimal fromBalance = getBalance(fromAccount);
    
    if (fromBalance.compareTo(amount) >= 0) {
        withdraw(fromAccount, amount);
        deposit(toAccount, amount);
    }
    // Никакие другие транзакции не смогут конкурировать
}

❌ НЕ рекомендуется для обычной таблицы пользователей — слишком медленно.

Рекомендация для таблицы пользователей

READ COMMITTED — оптимальный выбор, потому что:

1. Базовая безопасность — не видим незафиксированные данные
2. Хорошая производительность — позволяет параллельные обновления
3. Контроль доступа на уровне приложения — проверяем через код
4. Масштабируемость — не создаёт много блокировок

@Service
public class UserService {
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public void updateUserProfile(Long userId, UserUpdateRequest request) {
        // Проверяем, что пользователь может изменять свои данные
        User currentUser = getCurrentUser();
        
        if (!currentUser.getId().equals(userId) && !currentUser.isAdmin()) {
            throw new AccessDeniedException("Только администратор может изменять чужие данные");
        }
        
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException("Пользователь не найден"));
        
        user.setEmail(request.getEmail());
        user.setPhone(request.getPhone());
        user.setLastModified(LocalDateTime.now(ZoneOffset.UTC));
        
        userRepository.save(user);
    }
    
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public void adminUpdateUser(Long userId, AdminUserUpdateRequest request) {
        // Администратор может изменять любые поля
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException("Пользователь не найден"));
        
        user.setEmail(request.getEmail());
        user.setRole(request.getRole());
        user.setStatus(request.getStatus());
        user.setLastModified(LocalDateTime.now(ZoneOffset.UTC));
        
        userRepository.save(user);
    }
}

Если нужна повышенная защита: REPEATABLE READ

Используй REPEATABLE READ если:

• Критичны дублирующиеся чтения в одной операции
• Работаешь с MongoDB или MySQL (там это дефолт)
• Выполняешь сложные многошаговые операции с одними и теми же данными

@Service
public class AdminReportService {
    @Transactional(isolation = Isolation.REPEATABLE_READ)
    public ReportDto generateUserReport() {
        // Первое чтение
        int totalUsers = countAllUsers();
        
        // Даже если другие транзакции добавляют пользователей,
        // мы видим консистентный снимок данных
        List<User> activeUsers = getActiveUsers();
        
        return new ReportDto(totalUsers, activeUsers.size());
    }
}

Практика: Выбор уровня изоляции

// Для простых CRUD операций
@Transactional(isolation = Isolation.READ_COMMITTED)
public void simpleUpdate(User user) { ... }

// Для отчётов и аналитики
@Transactional(isolation = Isolation.READ_COMMITTED, readOnly = true)
public List<UserStat> getStatistics() { ... }

// Для критичных финансовых операций
@Transactional(isolation = Isolation.REPEATABLE_READ)
public void criticalOperation() { ... }

// Для очень редких случаев с полной синхронизацией
@Transactional(isolation = Isolation.SERIALIZABLE)
public void extremelyCriticalOperation() { ... }

Заключение

Для таблицы пользователей, где каждый может менять свои данные, а администратор — любые:

• Выбирай READ COMMITTED — стандартный, быстрый, безопасный
• Контролируй доступ на уровне приложения — проверяй права пользователя
• Используй REPEATABLE READ, только если необходимо** — это медленнее
• Избегай SERIALIZABLE — слишком дорого для обычных операций
• Логируй изменения — веди audit log для отслеживания кто и когда менял данные