處理競賽情況

取得未讀信件數量

SELECT COUNT(*)
  FROM emails
 WHERE recipient_id = 2
   AND unread_flag = true

去正規化以提升效率

-- INSERT INTO emails ..
-- 新增完之後，再增加未讀信件的數量
UPDATE mailboxes
   SET unread = unread + 1
 WHERE recipient_id = 2;

使用者2 明明有新郵件，卻顯示 0

同時對單一值加一

隔離性

避免別的請求看得到你未完成的狀態。

容錯性

原子性

讓你可以放心捨棄請求

盡責性

我盡可能把事做好，但做過的事不能重來

交易機制

為什麼 ORM（Object-Relational Mapping）的框架通常不預設重做？

小節

• 並行（concurrency） → 競賽狀況
• 隔離性（isolation） → 避免/偵測
• 原子性（atomic） → 好復原

dirty-read

dirty-write

覆寫未完成的資料

加鎖，避免同時寫入

讀未完成的資料

等完成交易，再合併

讀取偏斜（read-skew）

多版本並行控制

賦予每個交易增量編號

索引

索引指向的地方涵蓋多版本的資料

情境：晚上醫院值班。

假體判定

寫入偏斜的變形

BEGIN TRANSACTION;

SELECT COUNT(*) FROM bookings
 WHERE room_id = 123
   AND end_time > '2000-01-01 12:00'
   AND start_time < '2000-01-01 13:00';

INSERT INTO bookings 
       (room_id, start_time, end_time, user_id)
VALUES (123, '2000-01-01 12:00', '2000-01-01 13:00', 666);

COMMIT;

限制狀態

SELECT COUNT(*)
  FROM users
 WHERE user_account = 'new_user'

INSERT INTO users
       (user_id, user_account)
VALUES (123, 'new_user');

• 實際序列化 - 沒辦法有效的擴增
• 兩階段鎖 - 會讓潛時很不穩
• 序列化快照 - 也許會是未來標準

很慢的讀取

• 多資料的讀取（OLAP）
• 磁碟讀取

互動式交易

1. 讀時取共享鎖，等待排他鎖被釋放
2. 寫時取排他鎖，等待所有鎖被釋放

假體判定怎麼辦

• 根據條件賦予預判鎖
• 鎖好鎖滿的範圍鎖

低落的效能

• 鎖來鎖去
• 閉鎖（deadlock）的釋放

• 偵測 → 退回交易
• 阻止 → 無法並行

判斷是否讀到舊資料

判斷寫入後是否影響其他人

效能和擴增性

• 允許並行，所以好用
• 實作細節影響判定是否衝突