Каким образом база данных защищает от проблем с состоянием гонки (Data Race)?

А, ну это про гонки в базах данных, да? Слушай, тут всё как в жизни — если два чувака одновременно пытаются снять деньги с одного счёта, то без правильного подхода будет полный пиздец. СУБД, конечно, не дураки, они придумали целую кучу механизмов, чтобы такого не было.

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

Уровни изоляции — это вообще отдельная песня. Их, блядь, несколько, и чем круче уровень, тем надёжнее, но и тем медленнее всё работает. Это как выбор оружия: можно пальнуть из рогатки, а можно из гаубицы.

• Read Uncommitted: Это вообще уровень распиздяйства. Транзакция может видеть даже те данные, которые другая транзакция ещё не зафиксировала, а только накакала и не успела смыть. Грязные чтения, одним словом. Использовать — это себя не уважать.
• Read Committed: Нормальный, рабочий уровень. Стандарт во многих базах. Гарантирует, что читаешь только закоммиченные данные. Но есть нюанс: если в середине своей транзакции дважды прочитаешь одну и ту же строку, то она может внезапно оказаться другой, потому что кто-то между твоими чтениями её изменил и зафиксировал. Неповторяющееся чтение, ёпта. Неприятно, но жить можно.
• Repeatable Read: Тут уже серьёзнее. Гарантирует, что строки, которые ты один раз прочитал, до конца твоей транзакции меняться не будут. Но! Может внезапно появиться новая строка, которой раньше не было. Это фантомное чтение. Как призрак, блядь, возник из ниоткуда.
• Serializable: А это уже тяжёлая артиллерия. Полная изоляция. Гарантирует, что результат будет такой, будто все транзакции выполнялись строго по очереди, одна за другой. Состояние гонки исключено полностью, но производительность иногда просит пощады. Используй, когда деньги переводятся или места в самолёте бронируются.

А ещё есть блокировки. Их два основных вида, как два подхода к жизни.

• Пессимистичные блокировки: Это когда ты сразу, с порога, всех посылаешь и говоришь "Не лезь, это моё!". В SQL это SELECT ... FOR UPDATE. Ты явно говоришь базе: "Я буду эту запись обновлять, так что пока я с ней не закончил, все остальные — на хуй, в очередь". Надёжно, но если все начнут так делать, то всё может встать колом.

BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- Всё, счёт №1 заблокирован, я его царь и бог
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

• Оптимистичный контроль (OCC): А это подход хитрожопого интеллигента. Ты работаешь так, будто конфликтов не будет. Читаешь данные, что-то с ними делаешь, а в момент сохранения проверяешь: "А не изменил ли кто эту запись пока я тут умничал?". Обычно для этого есть специальное поле-версия. Если не изменил — ок, сохраняем. Если изменил — ой, всё, получаем ошибку и начинаем свою операцию заново. Никого не блокировал, но в случае давки придётся переделывать.

// Допустим, в C# с EF Core
var product = await db.Products.FindAsync(id); // Прочитал, версию запомнил
product.Quantity--;
try
{
    await db.SaveChangesAsync(); // Сохраняю, и EF Core тихонько проверит в WHERE, та ли ещё версия
}
catch (DbUpdateConcurrencyException) // Ага! Пока я думал, кто-то уже купил!
{
    // Ну всё, пизда. Придётся заново товар загружать и логику повторять.
}

И вишенка на торте — MVCC (Multiversion Concurrency Control). Эту штуку любят PostgreSQL и другие продвинутые СУБД. Суть в том, что база хранит несколько версий одной строки. Каждая транзакция видит снимок данных на момент своего начала. Это позволяет читающим транзакциям не ждать пишущих и не блокировать их — просто читается нужная версия. Гениально и эффективно, но место на диске жрёт.

Так что же делать на практике? Если пишешь что-то критичное, вроде списания денег:

1. Либо юзай высокий уровень изоляции вроде Serializable.
2. Либо явно хватай запись на пессимистичную блокировку через FOR UPDATE.
3. Либо делай через оптимистичный контроль, но будь готов, что операцию иногда придётся перезапускать, если нарвешься на конфликт.

Выбирай, что больше подходит. Главное — не надеяться на авось, а то будет тебе хиросима в таблице bank_accounts.