昨天聊了下SQLSERVER的spinlock，當時我認為spinlock是與Oracle LATCH相對應的結構，事實上碎片化的閱讀會帶來一些知識掌握的不準確。Oracle的LATCH是通過spin來實現鎖的獲取的，spin是LATCH獲取輕量級鎖的一種方式。而在SQLSERVER中，LATCH和spinlock被設計成兩種輕量級鎖，分別用于不同的場景。Oracle有shared pool，library cache等結構，可以用shared pool閂鎖來保護整個共享池，共享池中新增的一些亂七八糟的數據結構可以通過shared pool閂鎖以及mutex來實現串行化訪問保護。

SQLSERVER中并無此類機制，因此對于一些重度訪問的內存結構，設計了LATCH來保護，而其他的一些數據結構，使用spinlock。在SQLSERVER中，總是使用spinlock來保護那些訪問十分快速的內存結構。

LATCH是 SQL Server 的SQL引擎用來保證內存結構的一致性的輕量級原子操作用來保護索引、數據頁和內部結構等結構，例如 B 樹中的非葉頁。LATCH僅存在于SQL引擎內部。SQL Server 使用緩沖LATCH來保護緩沖池中的頁面，并使用 I/O LATCH來保護尚未加載到緩沖池中的頁面。每當向 SQL Server 緩沖池中的頁面寫入或讀取數據時，工作線程必須首先獲取該頁面的緩沖LATCH。有多種緩沖LATCH類型可用于訪問緩沖池中的頁面，包括獨占LATCH (PAGELATCH_EX) 和共享LATCH(PAGELATCH_SH)。

當 SQL Server訪問一個尚未加載到緩沖池中的頁面時，將通過一個異步 I/O操作將該頁面加載到緩沖池中。如果 SQL Server 需要等待 I/O 子系統響應，它將根據請求類型等待獨占 (PAGEIOLATCH_EX) 或共享 (PAGEIOLATCH_SH) I/O LATCH；這樣做是為了防止另一個工作線程使用不兼容的LATCH將同一頁面加載到緩沖池中。LATCH還用于保護對緩沖池頁面以外的內部存儲器結構的訪問；這些被稱為非緩沖LATCH。

PAGELATCH的爭用在多 CPU 系統十分常見。當多個線程同時嘗試獲取相同內存結構的不兼容LATCH時，就會發生LATCH爭用。閂鎖是一種內部并發控制機制，SQL 引擎會自動確定何時使用它們。因為閂鎖的行為是確定性的，數據庫SCHEMA的設計，表、索引等的設計會影響閂鎖爭用。

非緩存頁的閂鎖名稱為LATCH_XX，其中“_XX”后綴表示了閂鎖的模式（PAGEIOLATCH/PAGELATCH也使用后綴表示模式）。SQL Server 的閂鎖模式可以總結如下：

lKP——保持LATCH，確保引用的結構不會被破壞。當線程想要查看緩沖區結構時使用。因為 KP LATCH兼容除銷毀（DT）之外的所有LATCH，因此 KP 閂鎖被認為是“輕量級”的，這意味著使用它時對性能的影響最小。由于 KP 閂鎖與 DT 閂鎖不兼容，它會阻止任何其他線程破壞引用的結構。KP 閂鎖將防止它引用的結構被lazywriter 進程破壞（臟塊寫盤并釋放緩沖）；

lSH -- 共享閂鎖，需要讀取引用的結構（例如讀取數據頁）。多個線程可以同時訪問共享閂鎖下的資源以進行讀取。

lUP——更新閂鎖，與 SH（共享閂鎖）和 KP 兼容，但不兼容其他閂鎖，因此不允許 EX 閂鎖寫入引用的結構。

lEX——獨占閂鎖，阻止其他線程寫入或讀取引用的結構。一個使用示例是修改頁面內容以保護頁面損壞。

lDT -- 銷毀閂鎖，必須在銷毀引用結構的內容之前獲取。例如，lazywriter 進程必須獲取一個 DT 閂鎖以釋放一個干凈的頁面，然后再將其添加到可供其他線程使用的空閑緩沖區列表中。

上面的描述中關于閂鎖兼容性的描述，可以用上表來表示。如果我們看到一個閂鎖，可以通過”_”之后的后綴來區分其模式。比如PAGEIOLATCH_EX是一個獨享的PAGEIOLATCH，LATCH_DT是一個非緩沖區保護的銷毀閂鎖。

和Oracle的子閂鎖類似，SQLSERVER也存在類似的結構，稱為superlatch或者sublatch。目的是使用多個子閂鎖來提高閂鎖的并發性能。SQLSERVER使用多線程結構，并采用緩沖區動態擴展的方式。因此superlatch機制與NUMA架構做了一些優化，使之更好的適應NUMA。

SuperLatches 可以提高訪問共享頁面的性能，其中多個并發運行的工作線程需要 SH 閂鎖。為此，SQL Server 引擎會將此類頁面上的閂鎖動態提升為 SuperLatch。

在為大型服務器設計的高吞吐量系統上，必定會出現高并發的閂鎖爭用，在此類系統中存在閂鎖爭用是十分正常的現象。但是當閂鎖爭用和閂鎖等待類型等待時間大到足以降低 CPU 利用率的情況下，系統的整體吞吐量會嚴重下降。識別和識別閂鎖爭用的跡象很重要，所以讓我們必須有能力來分析這種情況。SQL Server 閂鎖的預期行為（與每秒事務數相關）是每秒事務數將隨著平均 SQL Server 閂鎖等待時間的增加而增加，其本身以緩慢的速度增加。如果數據庫并發增長的趨勢與閂鎖等待的趨勢十分接近，那么閂鎖爭用并沒有產生額外的負面影響。如果閂鎖等待幅度遠遠超過數據庫負載的增長，那么就說明閂鎖出現了嚴重的爭用。這個判斷原則在大多數情況下是有效的。

我已經比較長時間沒有仔細閱讀數據庫廠商官方的白皮書了，通過這兩天的學習，我學到了一個分析數據的方法。實際上有些指標之間是存在較為同步的關聯關系的，通過上升或者下降的幅度（可以通過統計學方法計算出一個可評估的度量）之間的對比，可以發現一些系統的性能問題。以前我們做了一個指標關聯性分析工具，用于發現數據庫某個指標異常可能存在的問題。實際上用這種更為簡單的算法，也可以發現系統中存在的一些背離預期行為的場景，并用于告警。