鎖定和併發
8.3鎖定
Sql Server有幾種不一樣的方式來鎖定數據
舉例來講
更新鎖在更新操做的開頭部分獲取
讀操做獲取共享鎖,而寫操做獲取排它鎖
兩種獨立的鎖定體系
分類
第一種影響全部徹底共享的數據,並提供行級鎖、分頁鎖、表、數據分頁、LOB分頁以及索引分頁級別上的表級鎖
第二種SQL server 內部使用,用來處理索引併發控制,管理對於內部數據結構的訪問,以及獲取數據分頁的個別記錄,第二種系統採用閂latch,比鎖要少耗資源並能提供性能優化
區別
鎖保證邏輯一致性
閂保證物理一致性
自旋鎖
用戶數據的鎖定類型
概念
鎖的粒度granularity
行
分頁
一個索引鍵
索引鍵的一個範圍
一個擴展
表
鎖的全部權scope
會話
事務
遊標
鎖的模式
分類
共享鎖shared lock
當數據被讀取時,sql server自動獲取共享鎖
共享鎖能夠被一張表、一個分頁、一個索引鍵、或一個單獨的行所持有
許多進程能夠在同一數據上持有共享鎖,可是沒有進程能夠在已經有一個共享鎖存在的狀況下,在該數據上獲取排它鎖
通常地當一個數據被讀取完畢以後,共享鎖當即釋放,可是可使用查詢提示或不一樣的事務隔離級別改變這種默認行爲
排它鎖exclusive lock
當數據被插入、修改、或刪除之後,sql server 會自動獲取數據上的排它鎖
一次只能有一個進程持有特定數據資源上的排它鎖
若是別的進程已經排他性地鎖定住某個進程所要申請的數據資源,那麼該進程沒法獲取任何類型的鎖
排它鎖會保留到事務結束爲止
這就意味着被修改的數據一般在當前事務提交或回滾以前對其餘進程來講是不可用的
其餘進程能夠經過查詢提示來讀取排他性鎖定的數據
更新鎖update lock
實際上並非一種獨立的鎖,他們是共享鎖和排它鎖的混合
當sql server執行一個數據修改操做,但首先須要搜索表以尋找到要被修改的資源時,更新鎖就會被獲取
經過使用查詢提示,一個進程能夠明確的申請更新鎖
提供對其餘數據讀者的兼容性,在確保數據自上次讀取之後還沒有修改的前提下,是進程可以在稍後對數據進行修改。
更新鎖不足以使用戶修改數據,全部的數據修改都要求被修改的資源上存在排它鎖
更新鎖的做用就好像一個串行化閥門,將後續申請排它鎖的請求壓入隊列中
只要有一個進程對資源持有更新鎖,其餘進程就沒法獲取該資源的更新鎖或排它鎖
而其餘正在申請相同資源的更新鎖或排它鎖就必須等待
持有更新鎖的進程能夠將其轉換爲排它鎖,由於更新鎖避免了與其餘進程的鎖的兼容性
能夠將更新鎖看做意圖更新intent to update
更新鎖一直保留到事務結束,或轉化爲排他鎖
SQL server使用更新鎖適用於任何須要在進行實際修改以前搜索數據的數據修改操做
這樣的操做包括受限更新和刪除
也包括帶有彙集索引的表進行插入操做
sql Server必須先搜索數據(使用匯集索引)以找到正確的位置來插入新的記錄
當sql server 只進行到搜索階段時,它會採用更新鎖來保護數據,而只有它找到正確的位置並開始插入之後纔將更新鎖升級爲排它鎖
意向鎖intent lock
特殊鎖定方式
架構穩定鎖schema stability locks
當查詢被編譯時,架構穩定鎖會防止其餘進程獲取架構修改鎖
架構更改鎖schema modification locks
大容量更新鎖bulk update locks
當執行bulk insert 或bcp工具將數據導入表時就會獲取大容量更新鎖
大容量導入操做必須使用tablock查詢提示來獲取這個特殊的鎖
鎖的模式決定了一個併發請求的鎖是否兼容sql