DEV Community: Mercy

[🗄️DataBase] ACID - Consistency

Mercy — Mon, 15 Jun 2026 12:03:35 +0000

1. ACID 簡單介紹

想像你要從 A 銀行轉帳 $100 到 B 銀行：

A 帳戶：-$100
B 帳戶：+$100

如果轉帳到一半伺服器當機，會發生什麼事？

如果只扣了 A 沒加 B → A 少了 $100，B 沒收到 → 錢消失
如果扣了 A 也加了 B → 正常，但當機沒影響
如果兩邊都扣了 → 明顯不對

ACID 就是用來保證這種操作不會出錯的四個規則：

A = Atomicity（原子性）：全部成功或全部失敗，沒有「只做一半」
C = Consistency（一致性）：操作前後，所有的規則都沒有被打破
I = Isolation（隔離性）：同時發生的操作，互相不要干擾
D = Durability（持久性）：一旦成功，資料不會無故消失

要注意 Atomicity ≠ Consistency

回到轉帳的故事：
Atomicity 保證了：A 扣 $100 和 B 加 $100 要嘛一起成功，要嘛一起失敗
Consistency 保證了：轉帳前 A+B 的總額 = 轉帳後 A+B 的總額
看出差別了嗎？
Atomicity 管的是「操作有沒有完整執行」，Consistency 管的是「操作完結果合不合理」。
即使 Atomicity、Isolation、Durability 都滿足了，還是可能違反Consistency。

2. Consistency 到底是什麼？

指的是交易開始前是合法的狀態，交易結束後也必須是合法的狀態。
這個「合法」不是法律上的合法，是「你定義的所有規則都沒有被打破」。

舉例來說

你規定：「冰箱裡的飲料不能少於 5 瓶。」

開始前：冰箱有 8 瓶 ✅
你拿走 2 瓶 → 還剩 6 瓶 ✅
你拿走 4 瓶 → 還剩 4 瓶 ❌（規則被打破）
你把冰箱洗劫一空 → 0 瓶 ❌（規則被打破）

Consistency 就是在檢查：
每一次你開關冰箱後，那個「不能少於 5 瓶」的規則還有沒有被遵守

同樣的道理，在資料庫裡就是：

規則類型	範例	誰來檢查
資料庫內建規則	Primary Key 不能重複、ForeignKey 不能指向不存在的資料、NOT NULL 欄位不能空、UNIQUE 不能重複	資料庫自動擋掉
應用層業務規則	「餘額不能為負」、「每天只能發 5 篇文」、「購物車總金額不得超過 $10,000」	你自己寫程式檢查

常見的誤區

很多人以為：「資料庫會自動保證一致性。」

資料庫只會保證 Primary Key 不重複、ForeignKey 正確指向這些「內建規則」。
但你寫的業務規則，像「餘額不能負的」、「每天提款上限 $30,000」，資料庫根本不知道。

Consistency 的最終責任在開發者身上。

3. Consistency 的兩個層面: 資料庫/應用層

3.1. 資料庫層級的 Consistency

這是資料庫幫你做的事，不用寫額外程式碼：

Entity Integrity：Primary Key 不能是 NULL
Referential Integrity：ForeignKey 必須指向存在的資料
Domain Integrity：欄位的型別、長度、格式必須正確（例如 INT 欄位不能存文字）
Unique Constraints：不能有重複值

-- 資料庫會幫你擋掉這些：
INSERT INTO users (id, email) VALUES (NULL, 'test@test.com');
-- ❌ Primary Key 不能為 NULL

INSERT INTO orders (user_id) VALUES (999);
-- ❌ 如果 user_id 999 不存在，FK 約束會拒絕

INSERT INTO products (price) VALUES (-100);
-- ❌ 如果有 CHECK(price >= 0) 約束

違反了資料庫直接拒絕操作，回傳錯誤。
你不需要寫任何業務邏輯來防止這種情況。

3.2. 應用層級的 Consistency

這是你自己要寫程式處理的，像是：

業務邏輯規則：例如「用戶餘額不能為負」、「訂單折扣不能超過 30%」
跨表狀態一致性：例如「A 表扣庫存時，B 表的訂單明細也要寫入」
衍生資料一致性：例如「快取裡的資料必須和資料庫一致」
操作紀錄的追蹤：例如「每次修改權限都要有操作記錄」

以業務邏輯規則的案例來看為何會違反應用層級的 Consistency :

違反的規則：用戶餘額不能為負（餘額必須 ≥ 0）

// 讀取和寫入之間有時間窗口
public async Task<bool> WithdrawAsync(int accountId, decimal amount)
{
    var account = await _db.Accounts.FindAsync(accountId);
    if (account.Balance < amount) return false;  

    account.Balance -= amount;
    await _db.SaveChangesAsync();
    return true;
}

這段程式碼的問題是，想像兩個人同時提款：

帳戶餘額 $100

Request 1（提款 $80）：讀到 Balance = $100 → 通過 → 寫入 $20
Request 2（提款 $70）：讀到 Balance = $100（髒資料）→ 通過 → 寫入 $30 ❌

最終餘額：$30（R1 扣的 $80 被覆蓋了，且 R2 基於過期資料做了錯誤決定）
正確應該要是：R1 扣成 $20 → R2 發現 $20 < $70，拒絕提款 → 最終 $20

這不是 Atomicity 的問題（每個扣款都完整執行），也不是資料庫層級的問題（沒有違反 PK/FK），而是應用層的 Consistency 被違反了。

這其實就是典型的 Lost Update（遺失更新）
指的是：兩個交易先後讀取了同一筆資料，各自做了判斷後寫入，後寫的那個把前一個的修改覆蓋掉了。

4. 如何達到 Consistency

Consistency 沒有單一解法，需要在資料庫約束、隔離層級、鎖機制、業務邏輯檢查等多方面做處理。

4.1. 資料庫層級：用 Constraints 建立防火牆

把你能想到的規則，盡可能用資料庫的 Constraints 表達出來，讓資料庫自動幫你檢查

Constraint	用途	範例
`PRIMARY KEY`	每筆資料都要有唯一識別	`id INT PRIMARY KEY`
`FOREIGN KEY`	確保關聯存在	`user_id INT REFERENCES users(id)`
`UNIQUE`	值不能重複	`email VARCHAR(255) UNIQUE`
`CHECK`	自訂條件	`CHECK (price >= 0)`
`NOT NULL`	欄位不能為空	`name VARCHAR(100) NOT NULL`

-- ✅ CHECK 約束：價格不能為負
CREATE TABLE products (
    id INT PRIMARY KEY,
    price DECIMAL(10,2) CHECK (price >= 0)
);

-- ✅ 違反時資料庫直接拒絕
INSERT INTO products (id, price) VALUES (1, -100);
-- ❌ ERROR: CHECK constraint violation

4.2. 應用層級：Consistency 需要 Isolation 來保護

前面 3.2 的提款範例有一個關鍵問題：沒有違反原子性 Atomicity，每個扣款都完整執行，但還是違反 Consistency 。

為什麼？因為 Isolation 不夠。

問題的本質

// 這段程式碼有 Transaction，也有 Atomicity，但還是錯了
public async Task<bool> WithdrawAsync(int accountId, decimal amount)
{
    var account = await _db.Accounts.FindAsync(accountId);  // 讀取
    if (account.Balance < amount) return false;             // 檢查
    account.Balance -= amount;                               // 寫入
    await _db.SaveChangesAsync();
    return true;
}

兩個請求同時進來：

餘額 $100
R1（取 $80）：讀到 $100 → 檢查通過 → 寫入 $20
R2（取 $70）：讀到 $100（還沒被 R1 提交蓋掉）→ 檢查通過 → 寫入 $30 ❌

問題出在「讀取」和「寫入」之間，另一個交易插了進來，讀到了舊資料。

要防止這種情況，就要靠隔離層級來控制一個交易能不能看到別人「還沒提交」的變更。

什麼是隔離層級 (Isolation Level)？

資料庫為了效能，不會讓交易真的排隊一個一個執行，而是讓它們同時跑。隔離層級就是在控制一件事：

一個交易能不能看到別人「還沒提交」的變更？

先搞懂「提交」是什麼意思：

在資料庫裡，你對資料做完修改後，要下 COMMIT 指令資料才算真的寫進去。
執行 COMMIT 之前，你的修改叫「還沒提交」。
這時候如果執行 ROLLBACK，修改就會取消，像沒發生過一樣。

回到提款的例子，R1 執行了 account.Balance -= amount 但還沒下 COMMIT：

R1 的修改：$100 → $20（還沒提交，隨時可以 ROLLBACK 取消）
R2 能不能看到這個 $20？ → 看隔離層級決定

各隔離層級對 Consistency 的保護程度：

隔離層級	白話解釋
Read Uncommitted	別人還沒 COMMIT 的資料你也看得到
Read Committed	只能看到別人已經 COMMIT 的資料
Repeatable Read	同一筆資料在這筆交易內，不管讀幾次結果都不變
Serializable	所有交易像排隊一個一個執行，互不干擾

舉例來說

原本餘額 $100，R1 取 $80，R2 取 $70：

Read Uncommitted（最弱）
  R1：讀到 $100 → 扣成 $20（還沒提交）
  R2：讀到 $20 ⚠️（看到 R1 還沒提交的變更）
       → $20 < $70 → 拒絕提款 ✅
  但如果 R1 最後 Rollback，R2 看到的 $20 就是髒資料 (Dirty Read)

Read Committed（通常資料庫的預設都是這個層級）
  R1：讀到 $100 → 扣成 $20（還沒提交）
  R2：讀到 $100（看不到 R1 未提交的 $20）
       → 檢查通過 → 扣成 $30 ❌ 結果超賣

Repeatable Read
  R1：讀到 $100 → 扣成 $20
  R2：讀到 $100 → 檢查通過 → 開始扣...
       └ 實際結果依資料庫而異：
         MySQL / SQL Server：UPDATE 會讀最新值 → 餘額變 -$50 ❌
         PostgreSQL：發現資料被改過 → 中止交易，報錯 ✅

Serializable
  R1：讀到 $100 → 扣成 $20
  R2：準備扣成 $30
       ❌ 資料庫發現衝突 → 中止 R2，請他重試

看到這邊你可能會想：「所以只有 Serializable 能解決問題？」
對，如果只靠隔離層級，確實只有 Serializable 保證安全。
但 Serializable 會把所有交易排隊執行，效能很差。

所以我們常常會搭配下面幾種方法一同做保護。

4.3. 原子操作：讓資料庫一次做完

為什麼前面 3.2 的寫法會出事？因為程式碼是分三步走的：

var account = await _db.Accounts.FindAsync(accountId);  // 步驟 1：讀取
if (account.Balance < amount) return false;             // 步驟 2：檢查
account.Balance -= amount;                              // 步驟 3：寫入

步驟 1 和步驟 3 之間，別人可以趁機插進來修改資料。

這個從「讀取」到「寫入」之間的空檔，就是所謂的 時間窗口。

時間窗口越長，別的交易插進來的機會就越大。

原子操作的思路：三步變一步

不要把「讀取 → 檢查 → 寫入」拆成三段程式碼分開執行，而是用一條 SQL 讓資料庫一次做完：

-- ✅ 庫存夠才扣，不夠則影響 0 筆，全程一條 SQL
UPDATE products SET stock = stock - 1 WHERE id = 1 AND stock >= 1;

這條 SQL 做的事情等於：

1. 讀取 stock          ← 資料庫內部一次完成
2. 檢查 stock >= 1     ← 資料庫內部一次完成
3. 夠的話就扣 1        ← 資料庫內部一次完成

因為檢查和寫入發生在同一條 SQL 裡，資料庫在執行這條 SQL 時不會讓其他人插隊，所以根本沒有時間窗口。

// ✅ 對應的 EF Core 寫法
var affected = await _db.Products
    .Where(p => p.Id == productId && p.Stock >= quantity)
    .ExecuteUpdateAsync(p => p.SetProperty(x => x.Stock, x => x.Stock - quantity));

if (affected == 0)
    throw new InvalidOperationException("庫存不足");

原子操作的優點

不需要 Transaction 也能保證一致性。 檢查和寫入在同一條 SQL 中完成，沒有時間差。

當你的操作可以濃縮成一條 SQL 時，等於資料庫幫你擋住了所有並發干擾。

什麼時候不該用

原子操作雖然簡單，但它有極限：

不適合的場景	原因	該用什麼
需要先讀取舊值做複雜判斷（eg. 計算每日提款總額、檢查折扣上限）	一條 SQL 塞不下這麼多邏輯	樂觀鎖（4.4）或悲觀鎖（4.5）
需要跨多個 table 保持同步（eg. 扣庫存 + 同時寫訂單明細）	單條 SQL 只能動一個 table	Transaction + 適當隔離層級
寫入後需要寫 Log 或發送通知	資料庫只管資料，不管 side effect	應用層處理 + Transaction

4.4. 樂觀鎖（Optimistic Locking）

適合衝突率低的場景，主要是在讀取資料時記下那筆資料的版本號，寫入時檢查版本號有沒有被別人改過。

舉例來說

想像兩位管理員同時打開商品編輯頁面：

管理員 A：讀到價格 $50 (version=1) → 改成 $100 → 存檔 → version 變 2 ✅
管理員 B：讀到價格 $50 (version=1) → 改成 $90 → 存檔 → version 已經是 2 了 → 拒絕 ❌

管理員 B 在開啟頁面到按下存檔之間，別人已經改過了。

樂觀鎖的做法很簡單：

每筆資料帶一個 version 欄位，寫入時檢查版本。

SQL 範例

UPDATE products SET price = @newPrice, version = version + 1
WHERE id = @id AND version = @oldVersion;
-- 管理員 B 傳入 @oldVersion = 1，但資料庫中的 version 已被 A 改成 2
-- WHERE version = 1 找不到資料 → 影響 0 筆 → 拋出 DbUpdateConcurrencyException

EF Core 實作

在 Entity 上加一個版本欄位，標記為 ConcurrencyToken：

public class Product
{
    public int Id { get; set; }
    public decimal Price { get; set; }
    public int Version { get; set; }  // 樂觀鎖欄位
}

var product = await _db.Products.FindAsync(productId);
product.Price = newPrice;

// EF Core 自動生成類似這樣的 SQL：
// UPDATE products SET price = @p0, version = version + 1
// WHERE id = @p1 AND version = @p2
// 如果影響 0 筆 → 拋出 DbUpdateConcurrencyException
await _db.SaveChangesAsync();

衝突發生後怎麼辦

try
{
    await _db.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException)
{
    // 重新載入最新資料
    var entry = _db.Entry(product);
    await entry.ReloadAsync();
    // 告訴使用者「資料已被別人修改，請重新確認」
    Console.WriteLine($"最新價格是 {product.Price}，請重新填寫");
}

樂觀鎖的特色是：不阻止並發，只偵測衝突

意思是讀取時不鎖資料，只是在寫入時才檢查

適用場景	不適用場景
一般 CRUD、後台管理操作	秒殺搶票
同一個人編輯自己的資料	高頻扣庫存
使用者很少同時改同一筆資料	會大量重試且重試成本高

4.5. 悲觀鎖（Pessimistic Locking）

如果今天的場景不是「兩個管理員修改商品價格」，
而是一千個人同時搶最後一件商品，樂觀鎖就不適用了。
因為每個人都會衝突，所以每個人都在 Retry，系統反而更慢

悲觀鎖的邏輯與樂觀所相反：

讀取時直接鎖起來，不讓別人碰，做完才解鎖

舉例來說

想像一個線上購物系統在特賣活動中，只剩最後一台筆電：

Request A（小明）：SELECT ... FOR UPDATE → 鎖住這筆資料 → 扣庫存 → Commit → 解鎖
Request B（小華）：                                             等到 A 解鎖才能讀 → 發現沒貨了

小華不是「讀到舊庫存然後扣失敗」，他是根本讀不到，直到 A 做完。

SQL 範例

BEGIN;
SELECT * FROM products WHERE id = 1 FOR UPDATE;  -- 鎖住 id=1 這筆
UPDATE products SET stock = stock - 1 WHERE id = 1;
COMMIT;  -- 解鎖

FOR UPDATE 的意思是：「我要鎖這筆，其他人要讀取或修改都請排隊。」

EF Core 實作

await using var tx = await _db.Database.BeginTransactionAsync(IsolationLevel.ReadCommitted);

// 鎖住這筆資料，其他交易要讀同一筆時必須等
var product = await _db.Products
    .FromSqlRaw("SELECT * FROM products WHERE id = {0} FOR UPDATE", productId)
    .FirstAsync();

if (product.Stock >= quantity)
{
    product.Stock -= quantity;
    await _db.SaveChangesAsync();
    await tx.CommitAsync();
}
// Transaction 結束 → 自動解鎖

代價：並行度降低

A 鎖住資料時，B 必須排隊等

所以要確保 Transaction 短小輕快，千萬不要在使用者填表單的過程中鎖資料，不然使用者填 10 分鐘，資料就鎖 10 分鐘。

而且如果 Transaction A 鎖了商品等訂單，Transaction B 鎖了訂單等商品，兩邊都在等對方釋放，就會造成死鎖。

有這種情況時，資料庫會自動偵測並中止其中一個，但你的程式碼要做好重試的處理。

樂觀鎖 vs 悲觀鎖

	樂觀鎖	悲觀鎖
什麼時候檢查衝突	寫入時才檢查	讀取時就直接鎖
衝突時的代價	重試一次	排隊等待
適合情境	衝突率低	衝突率高
讀取效能	高（不鎖）	低（要等鎖）
典型場景	修改文章、更新個人資料	搶購、扣庫存、扣款

4.6. 業務規則檢查：自己寫程式碼檢查

資料庫不知道你的業務規則，例如「每日提款上限 $30,000」、「折扣不能超過 30%」。

這些必須你自己寫程式碼檢查。

-- ❌ 資料庫不會幫你擋這個：
INSERT INTO transactions (user_id, amount) VALUES (1, 35000);
-- 即使超過日限額，資料庫照樣寫入，因為它不知道你的規則

// ✅ 你要自己檢查：
var todayTotal = await _db.Transactions
    .Where(t => t.UserId == userId && t.CreatedAt.Date == DateTime.UtcNow.Date)
    .SumAsync(t => t.Amount);

if (todayTotal + amount > 30000)
    throw new InvalidOperationException("每日提款上限 $30,000");

5. 總結

Consistency（一致性）的核心問題只有一個：交易結束後，你定義的規則還有沒有被遵守？

Consistency 不是資料庫單方面能保證的，它需要幾個層級來做保護：

資料庫 Constraints，例如 PK、FK、CHECK、UNIQUE 的基本防護
Transaction + 隔離層級 ，確保同時發生的操作不互相干擾
鎖機制（樂觀鎖 / 悲觀鎖），精確控制並發存取
業務規則檢查，只有開發者知道的業務規則，要自己寫程式檢查

沒有哪一招能搞定所有情況，應該要在不同的情境下，選用不同的工具組合。

[🗄️DataBase] Database Transactions 底層到底做了什麼：從記憶體到磁碟

Mercy — Sat, 13 Jun 2026 02:24:48 +0000

1. 為什麼要理解這件事

不管用哪個資料庫、哪種語言，你每天都在做類似的事

# Python + psycopg2 (PostgreSQL)
cur.execute("INSERT INTO roles (name) VALUES (%s)", ("admin",))
conn.commit()

// C# + EF Core
_db.Roles.Add(role);
await _db.SaveChangesAsync();
await tx.CommitAsync();

// Node.js + pg (PostgreSQL)
await client.query("INSERT INTO roles (name) VALUES ($1)", ["admin"]);
await client.query("COMMIT");

但你真的知道這些 API 背後發生了什麼事嗎？

ExecuteNonQuery() / SaveChangesAsync() 執行後，資料到底在哪？
什麼叫「在記憶體裡」？
Flush 和 Commit 有什麼差別？
Transaction 是怎麼保護你的資料的？

這篇文章會從 CPU 如何存取資料開始，一步步講到資料庫引擎怎麼保證你的資料不遺失。

2. 電腦儲存層級：從 Register 到 SSD

2.1 CPU Register（暫存器）

CPU 晶片內部有幾十個暫存器，每個 64-bit（以現代 x64 CPU 來說）。資料要被運算（加減乘除、比對大小），一定要先載到暫存器。

mov rax, [memory_address]   ; 從 RAM 搬到 CPU 暫存器
add rax, 1                  ; 在 CPU 裡面加 1
mov [memory_address], rax   ; 存回 RAM

前面例子寫的 role.name = "新名稱"，編譯器編譯後最終會變成好幾條這種機器指令，把值從一個 RAM 位址搬到 CPU，改完再搬回去。

屬性	值
容量	~幾十 bytes
速度	~0.3 ns
斷電是否消失	是

2.2 RAM（主記憶體）

RAM（Random Access Memory）是電容 + 電晶體做成的儲存陣列，每個 cell 儲存 1 bit 的電荷。優點是讀寫極快，缺點是斷電就全部消失。

256 GB RAM 大概有 2 兆個這樣的 cell。

你的變數全部存在這裡。
當你修改一個變數，你修改的是 RAM 中某個位址上的 byte。

屬性	值
容量	~GB ~ TB
速度	~50-100 ns
斷電是否消失	是

2.3 SSD / HDD（硬碟）

硬碟是最終儲存資料的地方。HDD 用磁碟片，SSD 用 NAND Flash 晶片。

屬性	HDD	SSD
速度	~5-10 ms	~10-100 μs
比 RAM 慢	~100,000 倍	~1,000 倍
斷電是否消失	否	否

3. 資料庫引擎核心架構：Page Cache、WAL、Checkpoint

不管哪個資料庫，設計目標都一樣：提供 ACID 保證，同時要有夠好的效能。

直接讀寫磁碟太慢了（比 RAM 慢 1000~100000 倍），所以所有資料庫都有一個核心機制：

你的程式 (Application)                    Database Engine
┌─────────────────────────┐        ┌──────────────────────────────────┐
│  Application Layer      │  SQL   │         Page Cache (RAM)          │
│  ┌───────────────────┐  │ ─────→ │  ┌──────┬──────┬──────┬───────┐  │
│  │ 資料 (物件/row)    │  │        │  │Page 1│Page 2│Page 3│ ...   │  │
│  │ SQL 語句           │  │        │  │ dirty│ clean│ dirty│       │  │
│  └───────────────────┘  │        │  └──┬───┴──────┴──┬───┴───────┘  │
│                         │        │     │             │               │
│                         │        │     ↓             ↓               │
│                         │        │  Background    Background         │
│                         │        │  Writer        Checkpoint         │
│                         │        │     │             │               │
└─────────────────────────┘        │     ↓             ↓               │
                                    │  Write-Ahead Log  Data Files     │
                                    │  (WAL / Redo Log / Tx Log)       │
                                    │  (磁碟)           (磁碟)          │
                                    └──────────────────────────────────┘

假設你寫了一行：

UPDATE users SET name = 'Alice' WHERE id = 1;

你的程式把這行 SQL 丟給資料庫引擎。然後呢？

第一站：Application RAM（你的程式記憶體）

當你的程式執行：

var role = new Role { Name = "管理員" };
db.Roles.Add(role);

這筆資料只在你程式的記憶體裡（.NET managed heap / Python heap / 等等），還沒透過任何 API 送出去。

這時如果斷電，這筆資料一定消失。

第二站：Flush（送出 SQL）

db.SaveChangesAsync();          // EF Core
// 或
cmd.ExecuteNonQuery();          // ADO.NET
// 或
cur.execute("INSERT ...");     // psycopg2 (Python)

這步做了：

應用程式把 SQL 或資料透過 TCP/IP（或共用記憶體）送到 Database Engine
Database Engine 開始接手處理
資料正式離開你的行程記憶體，進入資料庫的管轄範圍

第三站：Page Cache（Buffer Pool）

資料庫不直接讀寫磁碟，原因很簡單，因為磁碟太慢了。
所以它在啟動時會跟 OS 要一大塊 RAM，叫 Page Cache。
每個資料庫叫法不同，做的事一模一樣：

資料庫	Page Cache 名稱	位置
PostgreSQL	shared_buffers	資料庫自己的記憶體
MySQL/InnoDB	innodb_buffer_pool	資料庫自己的記憶體
SQL Server	Buffer Pool	資料庫自己的記憶體
SQLite	Page Cache	行程內記憶體

資料庫收到你的 UPDATE 後，第一步是找到那筆資料所在的 Page：

先在 Page Cache 找有沒有這個 Page
有 → 直接拿來用（Cache Hit）
沒有 → 從磁碟載入 Page Cache（Cache Miss）

然後直接在這個 Page 上修改，再把該 Page 標記為 Dirty Page（跟磁碟版本不一致）。

但 Dirty Page 不能一直待在記憶體裡，不然機器斷電資料就不見了。

第四站：WAL（Write-Ahead Log）

所以資料庫做了一件非常重要的事，
在把 Dirty Page 寫回磁碟的資料檔之前，先把修改紀錄寫到 WAL。

流程有四步：

1. 收到 UPDATE / INSERT / DELETE SQL
2. 在 Page Cache 修改對應的 Page（Dirty）
3. 把「我做了什麼修改」寫到 Transaction Log（磁碟）
4. 回傳給用戶「完成了」

WAL 是順序寫入（sequential write），速度快。
它只是 append-only 的日誌，不會回頭修改舊紀錄。

一旦 WAL 寫完，這筆修改就算安全了，就算下一秒機器崩潰或是斷電，重啟時只要 replay WAL，就能復原到你剛修改完的狀態。

這時候資料檔可能還沒有被更新，但 Transaction Log 已經寫了。如果斷電，資料庫重新啟動時會讀 Transaction Log：

有 COMMIT 記錄 → Redo：把還沒寫回磁碟的修改重新套用
沒有 COMMIT 記錄 → Undo：把已做的修改還原

第五站：Commit

await tx.CommitAsync();       // EF Core
// 或
tx.Commit();                   // ADO.NET
// 或
conn.commit();                 // Python DB-API
// 或
COMMIT;                        // CLI

這行在 Transaction Log 中寫入一筆 COMMIT 記錄。

從這一刻起：

如果斷電，資料庫 Recovery 會把這筆資料還原（Redo）
其他連線可以看到這筆資料（隔離級別決定何時看到）

Flush vs Commit：差別在哪

用生活比喻，想像你是一個廚師，要做一道菜給客人：

動作	對應的程式操作	比喻
備料切菜	建立物件 / 組裝 SQL	在流理台上準備材料
下鍋煮	Flush（送出 SQL / SaveChanges）	煮好了，放在廚房檯面上
決定上菜	Commit	端出去給客人吃
覺得太鹹倒掉	Rollback	倒掉重做，反正客人沒看到

Flush: 把菜做好放在廚房檯面上，菜已經熟了（資料庫已執行），但還沒端出去（還沒 Commit），客人看不到，萬一覺得不好吃還可以倒掉（Rollback）。

Commit: 端出去給客人吃，一旦端出去了就來不及了（永久的）。

第六站：Background Writer

Dirty Page 還是要寫回資料檔的，但資料檔是隨機寫入（random write），慢很多。
如果一次大量寫，使用者的查詢就會被卡住。

所以 Background Writer 在後台默默、慢慢地把 Dirty Page 刷回磁碟的資料檔。每次只刷一點點，不搶頻寬，讓使用者感覺不到它的存在。

第七站：Checkpoint

Background Writer 平常一直在刷，但總有一些 Page 它來不及刷，或累積太多 Dirty Page。

Checkpoint 的工作就是定時強制把所有髒 Page 刷回磁碟。
做完之後告訴 WAL：「這之前的日誌都已經同步了，可以砍掉了。」

這樣 WAL 不會無限膨脹，也縮短了崩潰後 recovery 的時間，只需要 replay checkpoint 之後的 WAL 就夠了。

崩潰怎麼辦：Recovery

機器永遠會 crash，這時就需要 ARIES 演算法來救。

ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）是資料庫崩潰後如何自動救回來的標準流程，所有現代關聯式資料庫（InnoDB、SQL Server、PostgreSQL、Oracle）都在用：

Analysis — 掃 WAL，查出哪些 Page 是髒的、哪些交易還沒結束
Redo — 從上一個 checkpoint 開始，把所有修改重新做一遍（不管有沒有寫回資料檔），確保資料檔跟 crash 瞬間一致
Undo — 把 crash 時還沒 commit 的交易全部還原

不管你 crash 前做過什麼，redo 全部重做一次，再把沒做完的 undo 掉，結果就是對的。

之所以叫 ARIES，是因為它利用 WAL 裡的語義資訊（知道每筆修改對應哪個 page、哪個 transaction），不需要猜測。

總結流程：

先寫 WAL（按順序寫，保證崩潰安全）→ Background Worker 慢慢刷 Dirty Page 回資料檔（隨機寫）→ Checkpoint 定時總整理、截斷 WAL

4. 實際範例

用一個典型的業務情境：建立一個新角色，同步身分認證資料，記錄稽核日誌。

4.1 沒有 Transaction

# Python pseudo code
db.roles.insert({"name": "admin"})
# 隱含 AUTO COMMIT

ensure_identity_role("admin")
# 內部也有自己的 AUTO COMMIT

audit_service.log("RoleCreated", "admin")
# 隱含 AUTO COMMIT

資料流向：

第 1 次 flush →  DB Page Cache: ✅ INSERT INTO roles
                 Transaction Log:  ✅ INSERT + AUTO COMMIT
                 → 已「永久」

第 2 次 flush →  DB Page Cache: ✅ INSERT INTO identity_roles
                 Transaction Log:  ✅ INSERT + AUTO COMMIT
                 → 又「永久」

第 3 次 flush →  DB Page Cache: ✅ INSERT INTO audit_logs
                 Transaction Log:  ✅ INSERT + AUTO COMMIT
                 → 又「永久」

如果第 1 次 flush 後、第 2 次 flush 前斷電：

資料表 (Table)	DB Recovery 後的狀態	關鍵原因說明
`roles`	存在	第一次 Flush 時，觸發 AUTO COMMIT 永久落地
`identity_roles`	不存在	寫入前系統已崩潰，Transaction Log 無此記錄
`audit_logs`	不存在	寫入前系統已崩潰，Transaction Log 無此記錄

資料庫處於不一致狀態，而且無法恢復。

4.2 有 Transaction

with db.begin_transaction() as tx:
    db.roles.insert({"name": "admin"})
    ensure_identity_role("admin")
    audit_service.log("RoleCreated", "admin")
    tx.commit()

資料流向：

執行動作 / 程式碼	DB Page Cache 狀態	Transaction Log 狀態	結果說明
`db.begin_transaction()`	無變更	BEGIN TRAN	交易正式開始，開啟安全保護傘
`roles.insert()`	INSERT roles	INSERT (無 COMMIT)	資料暫存於快取，尚未真正生效
`ensure_identity_role()`	INSERT identity_roles	INSERT (無 COMMIT)	資料暫存於快取，尚未真正生效
`audit_service.log()`	INSERT audit_logs	INSERT (無 COMMIT)	資料暫存於快取，尚未真正生效
`tx.commit()`	保持不變 (等待 Checkpoint)	COMMIT	日誌強制落地，三筆資料同時正式生效

如果 commit 前斷電：

DB Recovery 後：
  Transaction Log 中沒有 COMMIT 記錄
  → 全部三筆 INSERT 都被 Rollback（Undo）
  → 資料庫像沒發生過一樣

重新執行一次即可，不會有任何殘留資料。

5. 總結

資料從應用程式到磁碟，並不是一步到位

它會先存在 Application RAM，接著透過 Flush 送進 Database Engine，在 Page Cache 中修改資料頁，並寫入 WAL / Transaction Log。

只有當 Transaction Log 中出現 COMMIT 記錄時，這筆交易才正式成立。

至於 Dirty Page 什麼時候真正寫回 Data Files，通常是之後由 Checkpoint 或 背景程序 完成。

整個流程為：

Application RAM → Flush → Page Cache + WAL → Commit → Checkpoint → Data Files

[🗄️DataBase] ACID - Atomicity

Mercy — Thu, 11 Jun 2026 08:02:12 +0000

什麼是 ACID？

ACID 是資料庫交易（Transaction）的四個基本特性，確保資料操作的正確性與可靠性：

特性	中文	說明
Atomicity	原子性	交易內所有操作全部成功或全部失敗，不允許部分完成
Consistency	一致性	交易完成後，資料庫必須遵守所有原先定義的規則與約束 Ex.錢包餘額不可為負
Isolation	隔離性	多個並行交易的執行結果，彼此不能互相干擾
Durability	持久性	已提交的交易結果，即使系統崩潰也必須永久保存

什麼是 Atomicity？為什麼重要？

Atomicity 指的是：一個 transaction 內的所有操作，要馬全部成功，要馬全部當作沒發生過。

白話來說：資料處理不能做到一半失敗，然後資料庫留下一半髒資料。

違反 Atomicity 的真實案例

舉一個我在自己專案犯的錯誤

想像一筆玩家儲值交易因金流服務異常被標記為「異常交易」

系統修復後執行結案流程：

把異常交易狀態改成「已解決」
把儲值金額加到玩家的遊戲錢包
更新該玩家的累積儲值總額
記錄這筆操作到日誌（Audit Log）

如果步驟 2 失敗了，但步驟 1 已經存進資料庫

結果就是：異常交易顯示已解決，但錢根本沒進玩家錢包。玩家儲值不到帳，系統卻顯示已完成，這就是違反 Atomicity (原子性)。

以程式碼來看

async function resolveAbnormalTopUp(orderId: string) {
  const order = await db.topUpOrder.findUnique({
    where: { id: orderId },
  });

  if (!order) {
    throw new Error("找不到儲值訂單");
  }

  // 1. 先把異常交易狀態改成「已解決」
  await db.topUpOrder.update({
    where: { id: orderId },
    data: {
      status: "RESOLVED",
      resolvedAt: new Date(),
    },
  });

  // 2. 把儲值金額加到玩家錢包
  // 假設這一步因為 DB timeout、資料鎖定、網路問題而失敗
  await db.wallet.update({
    where: { playerId: order.playerId },
    data: {
      balance: {
        increment: order.amount,
      },
    },
  });

  // 3. 更新玩家累積儲值總額
  await db.player.update({
    where: { id: order.playerId },
    data: {
      totalTopUpAmount: {
        increment: order.amount,
      },
    },
  });

  // 4. 記錄 Audit Log
  await db.auditLog.create({
    data: {
      action: "RESOLVE_ABNORMAL_TOP_UP",
      playerId: order.playerId,
      orderId: order.id,
      amount: order.amount,
      message: "異常儲值訂單已結案並補發金額",
    },
  });
}

這段程式碼的問題是：每一步都直接寫入資料庫，但沒有包在同一個 transaction 裡。
只要某個步驟失敗了，資料就會變成不一致的狀態

正確做法：用 Transaction 包起來

因為這整個流程本來應該被視為 「同一筆交易」 ：
更新訂單狀態
+ 補發錢包金額
+ 更新累積儲值
+ 寫入日誌
typescript
要嘛全部成功，要嘛全部失敗，不能只有第一步成功，後面失敗。

以程式碼來看

async function resolveAbnormalTopUp(orderId: string) {
  await db.$transaction(async (tx) => {
    const order = await tx.topUpOrder.findUnique({
      where: { id: orderId },
    });

    if (!order) {
      throw new Error("找不到儲值訂單");
    }

    // 1. 更新異常交易狀態
    await tx.topUpOrder.update({
      where: { id: orderId },
      data: {
        status: "RESOLVED",
        resolvedAt: new Date(),
      },
    });

    // 2. 增加玩家錢包餘額
    await tx.wallet.update({
      where: { playerId: order.playerId },
      data: {
        balance: {
          increment: order.amount,
        },
      },
    });

    // 3. 更新玩家累積儲值總額
    await tx.player.update({
      where: { id: order.playerId },
      data: {
        totalTopUpAmount: {
          increment: order.amount,
        },
      },
    });

    // 4. 寫入 Audit Log
    await tx.auditLog.create({
      data: {
        action: "RESOLVE_ABNORMAL_TOP_UP",
        playerId: order.playerId,
        orderId: order.id,
        amount: order.amount,
        message: "異常儲值訂單已結案並補發金額",
      },
    });
  });
}

使用 transaction 之後，只要其中任何一步失敗，例如錢包更新失敗：
await tx.wallet.update(...)
整個 transaction 就會 rollback。
也就是前面已經執行過的步驟都會被還原，最後資料庫會保持在原本狀態
這樣就符合 Atomicity：這筆流程，要嘛完整成功，要嘛完全不發生。

[🗄️DataBase] N+1 Query Problem

Mercy — Wed, 10 Jun 2026 11:38:28 +0000

在做後端開發時，一定遇過這種情況：
👉 API 很單純
👉 查的資料也不多
👉 但效能就是「莫名其妙很慢」

認真查 log 才發現，SQL 被打了幾十次、幾百次，但你明明只寫了一個查詢
這種問題，通常不是你寫錯邏輯，而是踩到了N+1 Query Problem

所以什麼是 N+1 Query Problem 呢?

指的就是
為了取得一組資料，系統額外又發出了 N 次資料庫查詢

準確一點來說是
我們為了取得一組資料，會做兩件事

先執行 1 次查詢取得主資料
然後對每一筆資料，再各自發出 1 次查詢

以生活化的例子來看，想像你要查全班同學的成績：

你先去教務處問：「請問 301 班有哪些學生？」→ 拿到 30 個名字

然後你對每一個同學，都跑去教務處問一次：「XXX 的成績是多少？」

第 1 次：問全班名單
第 2 次：問小明的成績
第 3 次：問小華的成績
第 4 次：問小美的成績
...
第 31 次：問第 30 個同學的成績
總共 1 + 30 = 31 次跑教務處

這就是 N+1 —— N=30 個同學，多出 30 次額外查詢

比較聰明做法是
第 1 次就一次把全部同學的成績單拿回來，只要跑 1 趟

以程式碼來看

假設今天我們要做一個 API 回傳「商店列表 + 每家店的機器數量」
前端會拿到像這樣的資料：

{
  "total": 3,
  "items": [
    {
      "id": "A",
      "name": "Store A",
      "machineCount": 10
    },
    {
      "id": "B",
      "name": "Store B",
      "machineCount": 3
    },
    {
      "id": "C",
      "name": "Store C",
      "machineCount": 25
    }
  ]
}

第 1 次查詢：取得所有商店

var (items, total) = await _repo.GetStoresAsync(...);    // → SELECT * FROM Stores

第 2～N+1 次查詢：對每家店逐一問「你有幾台機器？」

foreach (var s in items)
{
    var count = await _repo.CountMachinesByStoreAsync(s.Id);  // → SELECT COUNT(*) FROM Machines WHERE StoreId = @p
}

如果分頁回傳 20 家店，那就是：
1 + 20 = 21 次 SQL 查詢 (N=20 家店，每家多 1 次)

那應該怎麼解決呢?

第一種解決方式: JOIN

這種情境，其實可以用一條 SQL 就解決
先把 Stores 跟 Machines join 起來，並用 COUNT 算出每家店的機器數量

SELECT
    s.Id,
    s.Name,
    COUNT(m.Id) AS MachineCount
FROM Stores s
LEFT JOIN Machines m ON m.StoreId = s.Id
GROUP BY s.Id, s.Name;

對應到 C#（EF / LINQ）
第 1 次：取得所有商店（不變）

var (items, total) = await _repo.GetStoresAsync(...);    // → SELECT * FROM Stores

第 2 次：一次把所有商店的機器數量算完

var items = await query
    .OrderBy(s => s.Code)
    .Skip((page - 1) * limit)
    .Take(limit)
    .GroupJoin(
        _db.Machines,
        s => s.Id,
        m => m.StoreId,
        (s, machines) => new StoreDto
        {
            Id = s.Id,
            Name = s.Name,
            MachineCount = machines.Count()
        })
    .ToListAsync();

第二種解決方式: batch query（批量查詢)

透過 GROUP+COUNT，一次把所有商店的機器數量算完

SELECT StoreId, COUNT(*)
FROM Machines
WHERE StoreId IN ('A', 'B', 'C', ...)
GROUP BY StoreId;

對應到 C#
第 1 次：取得所有商店（不變）

var (items, total) = await _repo.GetStoresAsync(...);    // → SELECT * FROM Stores

第 2 次：一次把所有商店的機器數量算完

var machineCounts = await _db.Machines
    .Where(m => storeIds.Contains(m.StoreId))    → WHERE "StoreId" IN (...)
    .GroupBy(m => m.StoreId)                    → GROUP BY "StoreId"
    .Select(g => new { StoreId = g.Key, Count = g.Count() })  → SELECT "StoreId", COUNT(*)
    .ToDictionaryAsync(x => x.StoreId, x => x.Count);

不需要第 3 次了，直接用 Dictionary 查出答案

var count = machineCounts.GetValueOrDefault(someStoreId, 0);

變成：1 + 1 = 2 次 SQL 查詢

等同於，用 SQL 來看：
原本（逐筆）：

SELECT COUNT(*) FROM Machines WHERE StoreId = 'A'   -- 第 1 次
SELECT COUNT(*) FROM Machines WHERE StoreId = 'B'   -- 第 2 次
SELECT COUNT(*) FROM Machines WHERE StoreId = 'C'   -- 第 3 次
...

改 batch 後（一次問完）：

SELECT "StoreId", COUNT(*)
FROM Machines
WHERE "StoreId" IN ('A', 'B', 'C', ...)    ← 一次問全部
GROUP BY "StoreId"                         ← 分組各自算

為什麼 JOIN 與 Batch 更快？

網路只來回 1 次而不是 N 次
每次資料庫查詢都有固定成本（連線、解析 SQL、交易開銷），N 次就把這些成本放大 N 倍
資料庫對一次問很多筆有優化處理（索引、快取）

JOIN 與 Batch 的核心優化，其實都在做同一件事：
👉 把 N 次查詢，變成一次（或少數幾次）查詢

下次在撈資料前可以先想想：

這段會不會產生 N 次 SQL？
能不能在進迴圈前就一次查完？

📄Paper: RORA-VLM: Robust Retrieval Augmentation for Vision Language Models

Mercy — Fri, 29 May 2026 04:13:04 +0000

Public At
International Conference on Learning Representations (ICLR) 2025

💡 Why I read this
最近在找論文的 idea 剛好找到這篇，發表在 ICLR 2025，不過被 Reject 了有點可惜
這篇主要是把 RAG 應用到 VLM ，讓模型在回答問題時可以利用外部知識
在很多 VQA 的任務中，答案其實不在圖片裡面，而是需要額外的背景知識
例如一張圖顯示一種鳥，問題是：「這種鳥主要分布在哪裡？」
圖片只能讓你看出鳥長什麼樣，但像棲地這種資訊一定要查資料才知道
這篇主要在解決：「當 retrieved knowledge 有 noise 時，VLM 怎麼還能穩定推理？

🧠 Core idea

作者提出一個 robust retrieval framework 給 VLM：

1. Two-stage retrieval

先用 image retrieve 相似 entity，再用 entity expansion 做 text retrieval。

在第一個階段，他們把 query image 當作一個「anchor」，去資料庫裡找很多長得很像的圖片。

他們用的資料庫叫 WIT，裡面有 3700 萬張圖片，每張圖片都搭配一個 entity 的名字跟描述。

在第二個階段，他們把在第一個階段拿到的 entity 名稱、描述加進原本的問題裡面，變成一個更具體的 query，再去用 google 查知識(call api)

✨ For Example

原本的問句:

which year was this building built?

找到的 Entity

Castle of Good Hope

新的 Query (原本的問句 + entity)

which year was Castle of Good Hope built?

2. Query-oriented visual token refinement

只保留和 query 最相關的 visual tokens，減少 image background noise。

一開始有兩個輸入：問題和圖片。
在 VLM 裡面，一張圖片會被切成很多塊，每個區塊會變成一個 visual token。

接下來，模型會根據問題的內容，計算每一塊(image patch) 和 query 的相關性。
與問題比較相關的區塊會被保留下來，不相關的就被忽略。

對於每一張檢索到的圖片，也會做一樣的篩選，用「query image 的比較重要的幾個 patch」來判斷，只留下和 query image 相關的區塊。

最後留下的這些區塊，會轉成對應的 visual tokens，並以 sequence 的形式排列(refined visual tokens)，作為 VLM 的 Input

也就是模型最後看到的圖片資訊，其實已經被篩選過了。

中間那些綠色的區塊，其實代表的是，每個 patch 和問題之間的相關性分數。

3. Noise-resilient RAG

training 時故意加入錯誤 retrieval，讓 model 學會忽略 irrelevant knowledge。

VLM 會同時看到：原始圖片、問題、還有多筆查到的知識（圖片 + 文字）

這些 retrieval 結果裡面，有些是正確的，有些是錯的。
模型要做的事就是根據相關程度(每張圖片與 query 到的 image)，決定要相信哪一段資訊。

👉 綠色 = 高 attention
👉 紅色 = 忽略

經過這個過程，模型可以回答問題，例如這個建築是在 1666–1679 年建造的。

✨ Full Workflow

📄Soure
https://openreview.net/pdf/1dff65b976d44f89183d623a8d26842e17ed51da.pdf

DEV Community: Mercy

[🗄️DataBase] ACID - Consistency

目錄

1. ACID 簡單介紹

要注意 Atomicity ≠ Consistency

2. Consistency 到底是什麼？

舉例來說

同樣的道理，在資料庫裡就是：

常見的誤區

3. Consistency 的兩個層面: 資料庫/應用層

3.1. 資料庫層級的 Consistency

3.2. 應用層級的 Consistency

4. 如何達到 Consistency

4.1. 資料庫層級：用 Constraints 建立防火牆

4.2. 應用層級：Consistency 需要 Isolation 來保護

問題的本質

什麼是隔離層級 (Isolation Level)？

舉例來說

4.3. 原子操作：讓資料庫一次做完

原子操作的思路：三步變一步

原子操作的優點

什麼時候不該用

4.4. 樂觀鎖（Optimistic Locking）

舉例來說

SQL 範例

EF Core 實作

衝突發生後怎麼辦

4.5. 悲觀鎖（Pessimistic Locking）

舉例來說

SQL 範例

EF Core 實作

代價：並行度降低

樂觀鎖 vs 悲觀鎖

4.6. 業務規則檢查：自己寫程式碼檢查

5. 總結

[🗄️DataBase] Database Transactions 底層到底做了什麼：從記憶體到磁碟

目錄

1. 為什麼要理解這件事

2. 電腦儲存層級：從 Register 到 SSD

2.1 CPU Register（暫存器）

2.2 RAM（主記憶體）

2.3 SSD / HDD（硬碟）

3. 資料庫引擎核心架構：Page Cache、WAL、Checkpoint

4. 實際範例

4.1 沒有 Transaction

4.2 有 Transaction

5. 總結

[🗄️DataBase] ACID - Atomicity

什麼是 ACID？

什麼是 Atomicity？為什麼重要？

違反 Atomicity 的真實案例

以程式碼來看

正確做法：用 Transaction 包起來

以程式碼來看

[🗄️DataBase] N+1 Query Problem

所以什麼是 N+1 Query Problem 呢?

以程式碼來看

那應該怎麼解決呢?

📄Paper: RORA-VLM: Robust Retrieval Augmentation for Vision Language Models

🧠 Core idea