本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 lock contention — 5 種 lock type + isolation level 互動 + production debug。

開場案例

Application 跑了 6 個月、staging 100% 重現過的 deadlock 從來沒在 production 出現。某天 traffic 上升 30%、production 開始爆 ER_LOCK_DEADLOCK、application retry 不夠快、order 大量失敗。

SHOW ENGINE INNODB STATUS\G 拉出 deadlock：

 1*** (1) TRANSACTION:
 2TRANSACTION 12345, ACTIVE 1 sec starting index read
 3mysql tables in use 1, locked 1
 4LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s)
 5MySQL thread id 100, query id 5000 update orders
 6UPDATE orders SET status = 'shipped' WHERE id = 500
 7
 8*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
 9RECORD LOCKS space id 50 page no 5 n bits 80 index PRIMARY of table `production`.`orders`
10trx id 12345 lock_mode X locks rec but not gap waiting
11
12*** (2) TRANSACTION:
13TRANSACTION 12346, ACTIVE 1 sec starting index read
14mysql tables in use 1, locked 1
154 lock struct(s), heap size 1136, 4 row lock(s)
16MySQL thread id 101, query id 5001 update payments
17UPDATE payments SET captured = 1 WHERE order_id = 500
18
19*** (2) HOLDS THE LOCK(S):
20RECORD LOCKS space id 50 page no 5 n bits 80 index PRIMARY of table `production`.`orders`
21trx id 12346 lock_mode X locks rec but not gap
22
23*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
24RECORD LOCKS space id 51 page no 10 n bits 80 index idx_order_id of table `production`.`payments`
25trx id 12346 lock_mode X waiting
26
27*** WE ROLL BACK TRANSACTION (1)

兩個 transaction 各自拿了一邊 lock、互相等對方的、deadlock。為什麼 staging 重現過、production 6 個月才爆？因為 lock contention 是 可能性 不是 確定性 — staging 重現等於確認「程式邏輯有 deadlock risk」、production 6 個月平安等於「concurrency 還沒撞到」。Traffic 上升把 機率乘以 N、原本每天 0 次變每分鐘 5 次。

這個 case 揭露 MySQL lock 教學的核心：理解 lock 不只是 debug 跑 deadlock 報錯 的能力、是 讀 query 預測 lock pattern 的能力。

InnoDB 5 種 Lock 類型

InnoDB 不是 簡單 row lock、有 5 個獨立 lock concept：

1. Record Lock — 鎖 row

SELECT ... FOR UPDATE / UPDATE / DELETE 對 被 match 的 row 加 record lock。

1-- Transaction 1
2BEGIN;
3SELECT * FROM orders WHERE id = 100 FOR UPDATE;
4-- 對 id=100 的 row 加 record lock

Transaction 2 試 UPDATE orders WHERE id = 100 必須等。

2. Gap Lock — 鎖 row 之間的「空隙」

InnoDB 在 REPEATABLE READ (預設) 下、SELECT ... FOR UPDATE WHERE col > 100 不只 lock 符合的 row、也 lock 該 range 內的「空隙」、防其他 transaction INSERT 進這個 range。

1-- 已存在 orders: id=100, 200, 300
2BEGIN;
3SELECT * FROM orders WHERE id > 100 AND id < 300 FOR UPDATE;
4-- Lock id=200 + gap lock (100, 200) + gap lock (200, 300)

Transaction 2 試 INSERT INTO orders (id) VALUES (150) 必須等 — 即使 id=150 不存在、gap lock 阻擋 INSERT。

Gap lock 是 deadlock 最常見來源 — application logic 看 row、但 lock 卻 cover row 之外的空隙、難預測。

3. Next-Key Lock — Record + Gap 組合

預設 lock 行為。SELECT ... FOR UPDATE WHERE col = 100 對 id=100 的 record lock + id=100 之前的 gap lock。

Lock 的範圍實際是 半開區間 (previous_id, current_id]：

1Records: 100, 200, 300
2
3WHERE id = 100 FOR UPDATE → next-key lock (-inf, 100]
4WHERE id = 200 FOR UPDATE → next-key lock (100, 200]
5WHERE id = 300 FOR UPDATE → next-key lock (200, 300]
6WHERE id BETWEEN 150 AND 250 FOR UPDATE → next-key lock (100, 200] + (200, 300]

4. Insert Intention Lock — INSERT 之前的 gap lock

INSERT 不直接 lock 整個 gap、而是 insert intention lock — 比 gap lock 弱、允許多個 INSERT 同 gap 並行（不同 id）。

1-- Transaction 1
2INSERT INTO orders (id) VALUES (150);
3-- Transaction 2
4INSERT INTO orders (id) VALUES (175);
5-- 同 gap (100, 200)、兩個 INSERT 並行、不阻塞

但如果 Transaction 1 已 hold gap lock（through SELECT FOR UPDATE）、Transaction 2 INSERT 必須等。

5. Auto-Inc Lock — Auto-Increment column 專用

INSERT INTO orders (id) VALUES (DEFAULT) 取得 auto-increment value 時 lock。Mode：

• innodb_autoinc_lock_mode=0（traditional）：lock 整個 INSERT statement 期間、其他 INSERT 必須等
• innodb_autoinc_lock_mode=1（consecutive）：lock 短時間（取值期間）、INSERT 1 row 不會阻塞其他
• innodb_autoinc_lock_mode=2（interleaved、8.0+ 預設（5.7 預設仍是 1））：完全並行、auto-inc value 不保證連續但可並行

8.0+ 預設 mode=2、性能高、但 binlog format 必須 ROW（STATEMENT 行為錯）。

Isolation Level 對 Lock 的決定性影響

InnoDB 4 個 isolation level、lock 行為完全不同：

REPEATABLE READ + Gap lock 是 deadlock 主要來源：

• 預設 isolation level
• 為了 保證 repeatable read（同 transaction 內讀同樣資料）、強制 gap lock 防 phantom row
• 但 gap lock 經常 lock 比預期廣的範圍、deadlock 機率上升

改成 READ COMMITTED 的取捨：

• 優點：無 gap lock、deadlock 大降、寫吞吐上升
• 缺點：transaction 內讀同 query 結果可能不同（non-repeatable read）
• 重要：binlog format 必須 ROW（STATEMENT 在 READ COMMITTED 下 replication 行為不一致）
• 多數 MySQL production 用 READ COMMITTED 跑 OLTP、REPEATABLE READ 留給特殊 case

對比 PostgreSQL：

• PG 預設 isolation 是 READ COMMITTED（不是 RR）
• PG 的 RR 用 snapshot isolation（不靠 gap lock）、deadlock 少
• 這是 MySQL 跟 PG 在 並行控制 model 的根本差異 — MySQL 用 lock-based、PG 用 MVCC-heavy

用 SHOW ENGINE INNODB STATUS 讀 lock 狀態

SHOW ENGINE INNODB STATUS\G 是 production debug lock contention 的主要工具：

 1------------
 2TRANSACTIONS
 3------------
 4Trx id counter 12350
 5Purge done for trx's n:o < 12340 undo n:o < 0 state: running but idle
 6History list length 5
 7
 8---TRANSACTION 12345, ACTIVE 30 sec  -- 長 transaction、警訊
 93 lock struct(s), heap size 1136, 5 row lock(s)
10MySQL thread id 100, OS thread handle ..., query id ...
11SELECT * FROM orders WHERE id > 100 FOR UPDATE
12------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK:
13RECORD LOCKS space id 50 page no 5 n bits 80 index PRIMARY of table `production`.`orders`
14trx id 12345 lock_mode X locks gap before rec  -- gap lock

關鍵欄位：

• ACTIVE N sec：transaction 跑多久（長 transaction 嫌疑）
• lock_mode X / S：exclusive / shared lock
• locks rec but not gap / locks gap before rec / locks rec：是 record / gap / next-key
• TRX HAS BEEN WAITING N SEC FOR THIS LOCK：等多久、超過幾秒就是 lock contention

SELECT * FROM information_schema.INNODB_TRX / INNODB_LOCKS (5.7) / performance_schema.data_locks (8.0) 給 structured lock 視圖。

5 個 Production 踩雷

1. Gap lock 阻塞 INSERT — 「Lock 不存在的 row」

1-- Transaction 1
2BEGIN;
3SELECT * FROM orders WHERE user_id = 100 FOR UPDATE;
4-- 假設 user_id=100 沒任何 order、預期沒 lock 任何 row
5
6-- Transaction 2
7INSERT INTO orders (user_id, amount) VALUES (100, 50);
8-- 等！為什麼？

問題：WHERE user_id = 100 沒有 record 時、InnoDB 仍 lock user_id=100 應該在的 gap（防 phantom）、Transaction 2 INSERT 進這個 gap 被阻擋。

修法：

• 改 READ COMMITTED isolation
• 或不用 SELECT ... FOR UPDATE on empty result、改 application 層 check + INSERT pattern
• 用 INSERT ... ON DUPLICATE KEY UPDATE 或 INSERT IGNORE 避免 SELECT FOR UPDATE

2. Auto-Inc Lock Contention — 大量並行 INSERT

innodb_autoinc_lock_mode=0 或 =1 模式下、大量並行 INSERT 撞 auto-inc lock、寫吞吐 cap。

修法：

• 設 innodb_autoinc_lock_mode=2（interleaved、8.0+ 預設（5.7 預設仍是 1））
• 確認 binlog_format=ROW（mode=2 必須）
• 接受 auto-inc value 不連續（id 可能跳號）

3. FK Lock Cascading — 父子 transaction 互鎖

1-- orders 表有 customer_id FK → customers.id
2-- Transaction 1
3UPDATE customers SET name = '...' WHERE id = 100;  -- lock customers row
4
5-- Transaction 2
6INSERT INTO orders (customer_id, amount) VALUES (100, 50);
7-- FK check 需要 lock customers row id=100、等 Transaction 1

FK 強制 每個 INSERT child 都要 shared lock parent、parent 的任何 UPDATE 都會 lock 所有 child INSERT。

修法：

• 評估 FK 是否真的需要（high-write 場景考慮 application-level enforcement）
• 短 transaction 縮短 lock 時間
• FK 設計時讓 parent UPDATE 少 / child INSERT 多（parent 是穩定資料）

4. Large Transaction Lock Holding — 1 個 transaction 拖全 cluster

1BEGIN;
2-- 100K row 的 batch UPDATE
3UPDATE orders SET status = 'archived' WHERE created_at < '2024-01-01';
4-- 跑 5 分鐘、持 100K row 的 lock
5-- 其他 transaction 撞到任何被 lock 的 row 都等 5 分鐘
6COMMIT;

長 transaction 是 lock contention 災難。

修法：

• 把 batch operation 拆 chunk（每 chunk 1000 row、commit、繼續）：

  1DO {
  2  START TRANSACTION;
  3  UPDATE orders SET status = 'archived'
  4  WHERE created_at < '2024-01-01' AND status != 'archived'
  5  LIMIT 1000;
  6  COMMIT;
  7} WHILE rows_affected > 0;

• 用 pt-archiver tool（Percona）對 batch UPDATE / DELETE 自動 chunked

• 監控 information_schema.innodb_trx 找出 long-running transaction

5. READ COMMITTED + Binlog ROW Interaction

READ COMMITTED isolation 改善 deadlock、但對 binlog format 有要求：

• binlog_format=STATEMENT：READ COMMITTED 下 transaction 看到不同 snapshot、replicate 後 replica 結果可能 不同於 primary（broken replication semantically）
• binlog_format=ROW：每個 row event 都 explicit、READ COMMITTED 跟 ROW 兼容、replica 結果一致
• binlog_format=MIXED：部分 case 仍可能 fall back STATEMENT、不推薦

修法：

• 用 READ COMMITTED 時、強制 binlog_format=ROW
• 全 cluster server（primary + replica + Group Replication members）統一 binlog_format
• Migration 5.7 STATEMENT → 8.0 ROW 時、isolation 跟 binlog format 一起 review

跟其他模組整合

跟 Replication

binlog_format=ROW 跟 isolation level 互動已述。Replica apply ROW binlog 時、replica 上 也 acquire 同樣 lock、replica 上的 long query 跟 replication lag 互動。詳見 Replication Topology。

跟 Group Replication

GR certification phase 跟 row lock 衝突 — write conflict 檢測在 certification、不是 lock。但 local row lock 仍存在、影響 single-instance write throughput。詳見 Group Replication。

跟 Online Schema Change

gh-ost / pt-osc 在 cut-over 階段需要 metadata lock、跟 long-running transaction 衝突。Lock contention deep dive 跟 OSC cut-over 議題密切。詳見 Online Schema Change Tools。

跟 Query Optimization

Slow query 持 lock 久、放大 contention。EXPLAIN ANALYZE 看實際執行時間、跟 lock holding time 直接相關。詳見 Query Optimization。

跟 InnoDB Tuning

innodb_lock_wait_timeout=50（預設 50 秒）— lock wait 超時 transaction 自動 rollback、避免無限等。production 建議調短（10-20 秒）、快 fail 給 application retry。詳見 InnoDB Tuning。

跟 PostgreSQL Lock model 對比

PG 用 MVCC 跑大部分並行 control、少數 case 才用 explicit lock、整體 deadlock 機率低。MySQL 用 lock-based + MVCC mixed、production 必須懂 lock pattern。

觀測 metric

Production 持續 monitor：

• Innodb_row_lock_waits / _time → lock wait 累計
• Innodb_deadlocks → deadlock 次數（5.7+ 有、之前要 parse SHOW ENGINE）
• performance_schema.data_lock_waits → 即時 lock wait 視圖（8.0+）
• information_schema.innodb_trx → long-running transaction
• slow_query_log → 看 query 是否花太多 time 在 lock wait

對 deadlock：把 innodb_print_all_deadlocks=ON、所有 deadlock 寫 error log、不用 SHOW ENGINE 才看到。

何時改 isolation level

相關連結

• MySQL vendor overview
• MySQL Replication Topology（binlog format + isolation 互動）
• MySQL Query Optimization（slow query → lock contention）
• MySQL InnoDB Tuning（lock_wait_timeout）
• MySQL Group Replication（cert vs lock）
• MySQL Online Schema Change（metadata lock）
• PostgreSQL MVCC + Lock Model（PG sibling、為什麼 PG 比 MySQL 少 deadlock — pure MVCC vs MVCC + gap lock）
• PostgreSQL vendor page（MVCC vs lock model）
• Isolation Level 卡片
• 官方：InnoDB Locking

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 MVCC + lock model — PG 並行控制機制跟跟 MySQL lock-based 不同。

PG MVCC：每次更新都 新增 tuple、不改舊版

PG 的並行控制核心是 Multi-Version Concurrency Control — UPDATE 不修改原 row、是 新增 一個 tuple version、舊 version 留在 table 直到 VACUUM 清理：

1原 row:    (id=1, status='pending', xmin=100, xmax=NULL)
2                 ↓ UPDATE status='shipped'
3新 tuple:  (id=1, status='shipped', xmin=200, xmax=NULL)
4舊 tuple 標 xmax=200（不刪、給其他 transaction 看舊 version）

xmin / xmax 是 creator transaction id / destroyer transaction id。每個 SELECT 用 snapshot（含當下 active transaction list）判斷哪些 tuple 對自己可見：

• 自己 transaction id > tuple.xmin 且 (tuple.xmax = NULL 或自己 transaction id < tuple.xmax) → 可見
• 否則 → 看不到（過去 / 未來版本）

結果：

• Readers 不 lock writers：SELECT 看 snapshot、不 block UPDATE
• Writers 不 lock readers：UPDATE 寫新 tuple、不影響正在跑的 SELECT snapshot
• Writers 只 lock 同一 row 的 writers：兩個 UPDATE 同 row 才 conflict

跟 MySQL InnoDB lock-based（Lock Contention）對比：

• MySQL：SELECT FOR UPDATE 用 gap lock 防 phantom、deadlock 機率高
• PG：MVCC + snapshot 自然防 phantom（read 看 snapshot）、deadlock 少

但 PG 代價是 VACUUM 治理 — dead tuple 不清理會佔 disk + 影響 query 效率。詳見 Autovacuum Tuning。

PG 4 種 lock

PG 仍有 lock、但場景跟 MySQL 不同：

1. Row-level lock — 主要由 UPDATE / DELETE / SELECT FOR UPDATE 取

1BEGIN;
2SELECT * FROM orders WHERE id = 100 FOR UPDATE;
3-- 對 id=100 row 加 ROW EXCLUSIVE lock
4-- 其他 transaction 試 UPDATE / DELETE id=100 必須等

Row-level lock 不 block reader（SELECT 看 snapshot、不檢查 lock）。

2. Table-level lock — DDL 跟少數 SELECT FOR 場景

PG 有 8 種 table lock mode、嚴重程度遞增：

DDL（ALTER / DROP）拿 ACCESS EXCLUSIVE、跟所有衝突。Production 跑 ALTER 必須短時間或走 Online Schema Change。

3. Advisory lock — Application 自己控

PG 提供 advisory lock 給 application 用、不關 row / table 結構：

1-- Session 1
2SELECT pg_advisory_lock(12345);
3-- 跑 critical section
4SELECT pg_advisory_unlock(12345);
5
6-- Session 2
7SELECT pg_try_advisory_lock(12345);  -- 試取、不阻塞、返回 false

用途：

• Application-level 互斥（如：cron job 同時只跑一個）
• 跨 connection 同步（PG-managed mutex）
• Distributed transaction coordinator（lightweight）

跟 row lock 不同：advisory lock 不關 row、application 自定義 lock ID 語義。

4. Predicate lock — SERIALIZABLE isolation 才用

PG SERIALIZABLE 用 Serializable Snapshot Isolation (SSI)、追蹤 predicate（query 條件）而不是 row：

1SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
2BEGIN;
3-- Predicate lock 紀錄這個 query 看了哪些 predicate
4SELECT * FROM orders WHERE status = 'pending';
5-- 其他 transaction INSERT pending order
6-- 提交時：PG 偵測 anomaly、rollback 之一
7COMMIT;

跟 MySQL gap lock 不同：

• MySQL gap lock：pre-lock、防 phantom 在 query 期間
• PG predicate lock：post-detect、commit 時偵測 anomaly、退回 transaction

PG SSI 對 寫入吞吐影響低（不 pre-lock）、但 transaction rollback 機率高（要 application retry）。

PG 預設 isolation：READ COMMITTED

PG 預設 READ COMMITTED、跟 MySQL InnoDB 預設 REPEATABLE READ 不同：

對 application code 含意：

• PG REPEATABLE READ 對 寫入吞吐 影響低（不 pre-lock、只 retry）
• 沒 gap lock → INSERT 不被 lock-induced 阻塞
• Deadlock 機率比 MySQL 低數量級

實務 PG production：用預設 READ COMMITTED 即可、SERIALIZABLE 留給 strict consistency 需求（金融 / 訂單）但接受 retry。

5 個 Production 踩雷

1. Idle transaction 卡 vacuum — Bloat 暴增

PG MVCC 仰賴 VACUUM 清理 dead tuple。VACUUM 只清理 沒 active transaction 看得到的 dead tuple。如果有 idle in transaction session 持續開著（application connection pool 連線忘關 transaction）、VACUUM 看不到 該 transaction snapshot 之後的 dead tuple、累積 bloat。

修法：

• 監控 pg_stat_activity 看 state = 'idle in transaction' 持續時間
• 設 idle_in_transaction_session_timeout = '5min' — 超時 PG 自動 kill 該 session
• Application connection pool 配置 不留 transaction 開著（如：pgBouncer transaction pool 自動 commit / rollback）

2. SELECT FOR UPDATE 跨 transaction — Application retry 麻煩

跟 MySQL 不同：PG SELECT FOR UPDATE 不會 block 其他 SELECT（讀仍可繼續）、但 block 其他 UPDATE / FOR UPDATE。若 application 在 transaction 內 SELECT FOR UPDATE、其他 transaction 等。

如果 application 設計 跨 transaction 持 lock（如：取 lock + return UI + 等用戶操作 + commit）、容易撞 idle in transaction 跟其他 transaction wait。

修法：

• Transaction 短：取 FOR UPDATE → 立刻處理 → commit、不跨 user interaction
• 跨 user interaction 用 advisory lock 或 application-level state machine、不依賴 row lock

3. Advisory lock 沒釋放 — Session 結束才自動釋放

pg_advisory_lock() 拿了、沒 pg_advisory_unlock()、lock 直到 session 結束 才自動釋放。Connection pool 重複使用同 connection、可能繼承前面留的 lock。

修法：

• 用 pg_advisory_lock 必 try/finally pg_advisory_unlock
• 或用 session-level 用 transaction-scoped：pg_advisory_xact_lock() — commit / rollback 自動釋放
• 監控 pg_locks 看 advisory lock count、長期累積是警訊

4. Bloat 不只是 vacuum 沒跑、是 active transaction 阻擋 vacuum

第 #1 點延伸：vacuum 已跑、但 bloat 仍持續成長、原因不是 vacuum 不夠、是 active transaction 阻擋 vacuum 看 dead tuple。

修法：

• 不只看 last_vacuum、看 VACUUM 跑了但沒收回多少
• SELECT * FROM pg_stat_progress_vacuum 看 VACUUM 進度
• SELECT * FROM pg_stat_activity WHERE backend_xmin IS NOT NULL ORDER BY backend_xmin — 看誰阻擋 vacuum
• 詳見 Autovacuum Tuning

5. SERIALIZABLE 下 transaction rollback — Application 必須 retry

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 後、PG SSI 偵測到 anomaly 會 rollback transaction、application 看到 serialization failure、必須 retry。

對 不知道要 retry 的 application、SERIALIZABLE 變 production bug。

修法：

• Application code 加 retry middleware：catch SQLSTATE 40001 (serialization_failure) → exponential backoff retry
• 不必所有 transaction 走 SERIALIZABLE — 只對 strict consistency 需求 場景 set
• 高並發 SERIALIZABLE workload 容易 rollback storm、考慮拆 transaction 縮短時間

觀測 metric

Production 監控：

• pg_stat_activity：active session / idle in transaction / wait_event
• pg_locks：當前 lock 列表、用 join 看誰 block 誰
• pg_stat_database.deadlocks：deadlock 計數（PG 較低、但仍要監控）
• pg_stat_user_tables.n_dead_tup / n_live_tup：dead tuple 比例 — bloat 指標
• pg_stat_progress_vacuum：VACUUM 進度

跟 MySQL Lock Model 對比

兩者解決同一問題（並行控制）、用不同策略。PG 用 空間換時間（保留多版本 tuple、讀寫不互鎖、但需 VACUUM 清理）、MySQL 用 時間換空間（lock 等待、但不必清舊版本）。

選擇判讀：

• High 並發 OLTP、寫 / 讀都重：PG MVCC 通常更好（讀不 block 寫）
• 簡單 OLTP + 不想管 VACUUM：MySQL InnoDB 對 ops 簡單
• 需要 SERIALIZABLE 強一致：PG SSI 對寫吞吐影響低
• 已有 MySQL 生態 / 工具鏈：MySQL Lock 知識可繼續用

詳見 MySQL Lock Contention — 完整 MySQL lock 機制。

跟其他模組整合

跟 Autovacuum Tuning

MVCC 仰賴 VACUUM、autovacuum 是 PG 並行控制的 維護成本。VACUUM 跑慢 / 沒跑 → bloat → query 慢。詳見 Autovacuum Tuning。

跟 Replication Topology

hot_standby_feedback = on 讓 standby 上 long-running query 不被 vacuum 取消、但 standby 把 oldest xmin 推回 primary、primary autovacuum 變保守、增加 bloat。詳見 Replication Topology。

跟 Connection Pool

pgBouncer transaction pooling 模式下、advisory lock / SELECT FOR UPDATE 跨 transaction 行為 broken（不同 transaction 可能進不同 backend connection）。詳見 pgBouncer Config。

跟 Query Optimization

長 transaction 跑慢 query 期間、其他 transaction 看到 snapshot bloat、planner 估錯 dead tuple ratio。詳見 Query Optimization。

相關連結

• PostgreSQL vendor overview
• PG Autovacuum Tuning（VACUUM 是 MVCC 必要成本）
• PG Replication Topology（hot_standby_feedback 影響）
• PG pgBouncer（transaction pooling 跟 lock 互動）
• PG Online Schema Change（DDL lock 議題）
• PG Query Optimization（snapshot bloat 影響 planner）
• MySQL Lock Contention（sibling、不同模型）
• Isolation Level 卡片
• 官方：PG MVCC / PG Concurrency Control / Explicit Locking