在 Oracle 資料庫並發控制體系中，Lock（鎖，內部稱 Enqueue）與 Latch（閂鎖）是兩大核心同步機制。雖然它們同屬「獨佔式資源鎖定」範疇，但設計初衷、運作邏輯、持有時長及性能調優切入點截然不同。混淆二者會導致錯誤的診斷方向，本文將從底層原理層面徹底釐清兩者邊界。
Lock 與 Latch 本質上都是為了解決多用戶並發訪問時的資源獨佔問題。若資料庫僅有單一 Session，則完全不需要鎖定機制。兩者皆屬「悲觀鎖」範疇，通過阻塞機制保證數據一致性與內存結構完整性。
| 維度 | Lock (Enqueue) | Latch |
|---|---|---|
| 保護對象 | 業務層面邏輯數據（表、行、事務等） | 內存結構（SGA 緩衝區、共享池、Library Cache 等） |
| 排隊機制 | 有序排隊（FIFO），先到先得，公平性高 | 無序搶佔（自旋 + 睡眠），先到不一定先得，依賴 CPU 時間片輪詢 |
| 持有時長 | 較長（毫秒至小時級），取決於事務邏輯 | 極短（微秒至毫秒級），僅保護內存操作瞬間 |
| 性能問題根因 | 業務設計缺陷（長事務、欠缺索引、熱點行更新） | 資料庫層面配置/代碼問題（未用綁定變量導致硬解析、熱塊爭用、共享池碎片） |
當 Session 請求已被佔用的 Lock 時，會被放入等待隊列尾部，按到達順序依次獲取。這種機制雖公平，但若持有者長時間不釋放（如未提交的大事務），會導致後續 Session 大面積阻塞，形成「連鎖阻塞」風險。
Latch 不維護隊列。請求失敗時，Session 進入「自旋」階段（佔用 CPU 反覆嘗試），自旋閾值耗盡後轉入「睡眠」階段（釋放 CPU，按指數退避喚醒）。此設計極大降低了內存結構保護的開銷，但也意味著高併發下可能出現「飢餓」現象。
cursor_sharing=FORCE 過渡shared_pool_sizeLock 是「業務邏輯的交通警察」，Latch 是「內存結構的極速閘機」。前者解決「誰先改這行數據」，後者解決「誰先碰這塊內存」。性能調優時，鎖問題找開發，閂鎖問題找 DBA，這句口訣能幫您快速定位責任邊界，避免無效溝通成本。
