SQL Server 與 Oracle 資料鎖定機制深度對比

核心差異：讀寫阻塞模型

架構根源

• SQL Server：傳統 **鎖基礎並發控制 (Lock-Based Concurrency)**。讀取需獲取 Shared Lock (S Lock)，寫入需 Exclusive Lock (X Lock)。S/X 互斥 → 讀寫互斥。為緩解，引入 **Row Versioning** (Snapshot Isolation, Read Committed Snapshot Isolation - RCSI) 但需顯式啟用並佔用 TempDB。
• Oracle：原生 **多版本並發控制 (MVCC / Read Consistency)**。每次查詢基於 **SCN (System Change Number)** 建立一致性快照，讀取滿足 `UNDO` 可重構的版本。**讀者不阻塞寫者，寫者不阻塞讀者** (唯一阻塞：寫寫衝突)。

實測演示 (SQL Server 阻塞讀取)

-- 窗口 1: 開啟交易更新
USE pubs; BEGIN TRAN;
UPDATE titles SET price = price * 1.05 WHERE title_id = 'BU2075';
-- 不 Commit

-- 窗口 2: 查詢同表
SELECT title_id, title, price FROM titles ORDER BY title_id;
-- 卡住轉圈，無法返回任何列 (含未更新列)，因表級/頁級 S Lock 被 X Lock 阻塞

Oracle 同場景下，查詢瞬間返回舊價格，完全不受更新交易影響。

效能與擴展性影響

SQL Server 緩解方案 (需權衡)

1. 啟用 Read Committed Snapshot Isolation (RCSI)：
   `ALTER DATABASE dbname SET READ_COMMITTED_SNAPSHOT ON;`
   讀取改用版本鏈 (TempDB)，不再獲取 S Lock。代價：TempDB I/O 暴增、版本清理延遲、寫入額外開銷 (14 bytes/行版本指標)。
2. Snapshot Isolation (SI)：事務級快照，需 `SET TRANSACTION ISOLATION LEVEL SNAPSHOT`，應用需處理更新衝突錯誤 (Error 3960)。
3. NOLOCK Hint (READ UNCOMMITTED)**：`SELECT ... FROM table WITH (NOLOCK)` — 髒讀風險，不可用於財務/核心業務。
4. 鎖粒度控制：`ROWLOCK`/`PAGLOCK`/`TABLOCK` Hint，避免不必要鎖升級。

Oracle 優勢場景

• 高併發 OLTP (電信計費、銀行核心、電商訂單) — 讀寫分離天然滿足。
• 長跑報表查詢與線上交易共存 — 報表讀一致性快照，零阻塞。
• 無需應用代碼修改即享受 MVCC — 透明於開發者。

總結

鎖模型決定了資料庫的並發天花板。SQL Server 預設鎖基礎模型導致「讀寫互斥」，在高併發混合負載下效能崩塌；Oracle 原生 MVCC 實現「讀寫不阻塞」，是支撐大規模關鍵任務系統的核心架構優勢。SQL Server 2005+ 引入 RCSI/SI 縮小差距，但引入 TempDB 依賴與應用複雜度，仍非原生透明方案。選型時，若業務屬「高併發、混合負載、零停機」、Oracle MVCC 為決策性優勢；若屬「中小規模、單純負載、Windows 生態綁定」、SQL Server 總擁有成本可能更低。