一.概述

　　在前幾章介紹過 sql server 效能調優資源等待之PAGEIOLATCH，PAGEIOLATCH是出現在sql server要和磁碟作互動的時候，所以加個IO兩個字。這次來介紹PAGELATCH。PAGELATCH型別是sqlserver在緩衝池裡的資料頁面上經常加的另一類latch鎖。

　　既然緩衝池裡的資料頁面與PAGELATCH有關係，那先來介紹資料頁面。

　　1. 資料頁面

　　資料頁面在"sql server 索引闡述系列二 索引儲存結構"中有詳細介紹,這裡講與PAGELATCH有關的知識點。 一個頁面包含頁頭，資料儲存，頁尾偏移量。 在頁頭裡包含了頁面屬性，頁面編號，記錄了當前頁面空閒的起始位置，當sqlserver 在要插入的時候，就能夠很快地找到插入的位置，而頁尾的偏移量記錄了每一條資料行所有頁中的位置，當需要查詢頁中資料時，通過頁尾的偏移量很快能定位。

　　當資料行發生變化時， sql server不但要去修改資料本身，還要維護頁中資料行與偏移量的關係。

       2.  PAGELATCH

　　講了這麼多關於資料頁面， 現在來理清一下關係， lock鎖是保證資料頁中資料的邏輯關係，PAGEIOLATCH的latch鎖是保證資料頁與磁碟進行儲存的關係，  PAGELATCH的latch鎖是保證資料頁中資料行與頁尾的偏移量的關係。當然這種區別介紹是為了更好的去理解它們之間的關係，PAGELATCH作用並不只是這點, 它還會維護系統頁面如SGAM,PFS,GAM頁面等。

　　3. HotPage現象

　　當我們為一個表建立主鍵自增ID時， 那麼sql server將按照ID欄位的值順序進行儲存，在大併發下，為了保證ID值按順序存放在資料頁中，這時PAGELATCH就會latch鎖住資料頁面裡的儲存結構， 使ID值排隊保持先後順序 。測試Hotpage現象可以是程式後端併發插入或使用 SQLIOSim工具來併發測試。

      下面來看一個簡單的圖：當前表裡有一個page 100的頁面， 該頁中已有二行資料(rid1和rid2) 分別對應著頁尾的偏移量1和2。 這時有二個插入任務，同時插入到page100頁，假設第一個任務申請到了ex_latch鎖，第二個任務就會等待，使資料行和偏移量對一 一對應。

　　由於資料頁的改動都是在記憶體中完成的，所以每次修改時間都應該非常短，幾乎可以忽略。如果該資源成為了sql server等待的瓶頸有以下幾種情況:

　　(1) sql server 沒有的明顯的記憶體和磁碟瓶頸。

       (2) 大量的併發集中在表裡的一個數據頁上叫hotpage

       (3) tempdb 臨時表也可以會成為瓶頸，通常可以通過增加tempdb檔案來緩解。 具體檢視Tempdb怎麼會成為效能瓶頸？。

     4. 檢視PAGELATCH現象

       4.1 通過sys.dm_exec_query_stats來檢視例項級別的等待

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'pagelatch%' 
order by  wait_time_ms desc

         在例項級別中等待次數最多的是PAGELATCH_EX的latch 排它鎖, 平均每次耗時90毫秒，這個平均值應該是不會有效能問題。

       4.2 能過sys.dm_exec_requests 來實時檢視sql語句級, 可以採用不定時監聽能過session_id來獲取sql 語句所對應的表，以及等待的資料頁型別 。

SELECT * FROM sys.dm_exec_requests  WHERE wait_type LIKE 'pagelatch%'

   5.  解決思路

　　(1)  通過設計表結構，使hotpage現象由單面的併發訪問，分散到多個頁面。

　　(2)  如果是在identity欄位上有瓶頸， 可以建立多個分割槽，因為每個分割槽都有自己的儲存單位，這樣hot 單頁現象就分散了。