您现在的位置：程式碼之家 >> 數據庫知識 > >> Oracle 資料庫 >> Oracle 資料庫基礎

Oracle 進階鎖機制深度解析：從基礎鎖類型到 DML 鎖實戰

編輯：Oracle 資料庫基礎

前言：為什麼需要鎖？

資料庫是多使用者共享的資源。當多個交易並發存取相同資料時，若缺乏並發控制，將導致 髒讀、不可重複讀、幻讀 等問題，破壞資料庫一致性。鎖機制正是解決此問題的核心技術——透過限制對資料物件的並發操作，確保交易的 ACID 特性。

一、兩大基礎鎖類型

二、Oracle 鎖分類總覽

依保護對象不同，Oracle 鎖分為三大類：

DML 鎖：保護資料完整性（表級鎖 TM、行級鎖 TX）
DDL 鎖：保護物件結構定義（表、索引等）
內部鎖與 Latch：保護 SGA 內部結構（DBA 關注重點）

開發人員最常接觸的是 DML 鎖，包含：

TM 鎖（Table Lock）：表級鎖，執行 DML 時自動申請
TX 鎖（Transaction Lock）：行級鎖/交易鎖，實際鎖定資料行

三、TM 鎖模式詳細對照表

Oracle 使用數值 0-6 表示不同鎖模式：

鎖類型	代碼	行為	相容性
共享鎖	S Lock	允許其他交易讀取，禁止修改	與 S 鎖相容，與 X 鎖衝突
排他鎖	X Lock	禁止其他交易讀取與修改	與任何鎖皆衝突

值	模式代碼	鎖模式名稱	描述	觸發 SQL 操作
0	NONE	無鎖	-	-
1	NULL	空鎖	無實際限制	SELECT
2	SS (Row-S)	行級共享鎖	允許查詢，禁止排他鎖	SELECT FOR UPDATE, LOCK TABLE ... IN ROW SHARE MODE
3	SX (Row-X)	行級排他鎖	允許查詢，禁止 DML	INSERT, UPDATE, DELETE, LOCK TABLE ... IN ROW EXCLUSIVE MODE
4	S	共享鎖	允許查詢，禁止任何 DML	LOCK TABLE ... IN SHARE MODE
5	SSX	共享排他鎖	僅允許查詢	LOCK TABLE ... IN SHARE ROW EXCLUSIVE MODE
6	X	排他鎖	完全獨佔	LOCK TABLE ... IN EXCLUSIVE MODE, DDL 操作

四、鎖升級與相容性檢查機制

當執行 DML 時：

系統先在目標表申請 TM 鎖
TM 鎖獲取後，再申請 TX 鎖 並標記具體資料行
後續交易只需檢查 TM 鎖模式相容性，無需逐行檢查 TX 鎖，大幅提升效能

五、實戰：查詢與監控鎖資訊

1. 查詢當前鎖等待情況

SELECT 
  s.sid, s.serial#, s.username,
  l.type, l.lmode, l.request,
  o.object_name,
  DECODE(l.lmode, 0,'NONE',1,'NULL',2,'ROW-S',3,'ROW-X',4,'SHARE',5,'S/ROW-X',6,'EXCLUSIVE') held_mode,
  DECODE(l.request, 0,'NONE',1,'NULL',2,'ROW-S',3,'ROW-X',4,'SHARE',5,'S/ROW-X',6,'EXCLUSIVE') requested_mode
FROM v$lock l
JOIN v$session s ON l.sid = s.sid
LEFT JOIN dba_objects o ON l.id1 = o.object_id
WHERE l.request > 0 OR l.lmode > 0
ORDER BY s.sid;

2. 找出阻塞鏈

SELECT 
  blocking_session,
  sid,
  seconds_in_wait,
  wait_class,
  event
FROM v$session
WHERE blocking_session IS NOT NULL;

六、常見鎖爭用場景與解決策略

場景	現象	解決方案
未提交的大量 DML	大量 Row-X 鎖導致其他 DML 等待	縮短交易長度、批次提交、優化索引減少掃描範圍
外鍵無索引	父表刪除/更新導致子表全表鎖	為外鍵欄位建立索引
不當的 LOCK TABLE	人為加鎖過度	避免使用 EXCLUSIVE 模式，改用 ROW SHARE/ROW EXCLUSIVE
位圖索引並發	大量鎖衝突	OLTP 環境避免位圖索引，改用 B-tree