Простая аналогия, представьте, что работаете с Git:
1. Вы создаёте ветку → делаете коммиты → нажимаете git push
2. А кто-то другой уже запушил изменения в main
3. Git говорит: «Конфликт! Сделайте pull и смержите»
4. Вы подтягиваете изменения, разрешаете конфликт → пушите снова ✅
Как это работает в БД:
-- 1. Читаем данные + версию
SELECT balance, version FROM accounts WHERE id = 123;
-- Получаем: balance=100, version=5
-- 2. Меняем у себя в коде
new_balance = 150
new_version = 6
-- 3. Пытаемся сохранить с проверкой версии
UPDATE accounts
SET balance = 150, version = 6
WHERE id = 123 AND version = 5;
-- Если обновлено 0 строк → КОНФЛИКТ! Начинаем с начала
-- Кто-то уже сохранил version=6
Когда применимо:
- Ожидаются редкие конфликты
- Пользователь думает минуты между чтением и сохранением
- Можно откатить транзакцию и начать заново
- Изменяется ограниченный набор строк
Мораль:
Блокировка данных — это дорого.
Конфликт версий — это дёшево.
Оптимистичная блокировка выбирает дешёвый путь, пока он работает.