對象
① 鎖：每條SQL語句
② 隔離：事務
鎖
①
并發問題
丟失更新
未確認的讀取（臟讀）
不一致的分析（非重復讀）：多次讀取相同的數據（行）不一致（其他用戶更改update）
幻像讀：多次讀取有不存在和新增的數據（其他用戶插入insert或刪除delete）
隔離級別
|
隔離級別
|
臟讀
|
不可重復讀取
|
幻像
|
說明
|
|
未提交讀(read uncommitted)
|
是
|
是
|
是
|
如果其他事務更新，不管是否提交，立即執行
|
|
提交讀(read committed默認)
|
否
|
是
|
是
|
讀取提交過的數據。如果其他事務更新沒提交，則等待
|
|
可重復讀(repeatable read)
|
否
|
否
|
是
|
查詢期間，不允許其他事務update
|
|
可串行讀(serializable)
|
否
|
否
|
否
|
查詢期間，不允許其他事務insert或delete
|
提交讀
假設存在表A，如下所示
|
A1
|
A2
|
A3
|
|
11
|
21
|
31
|
|
12
|
22
|
32
|
打開查詢分析器并打開兩個連接，分別輸入如下兩個事務：
--事務Ⅰ
SET TRANSACTION ISOLATION LEVEL READ Committed
begin tran
update A set A2 = 20 where A1 = 11
waitfor delay '00:00:10'
rollback tran
--事務Ⅱ
SET TRANSACTION ISOLATION LEVEL READ Committed
select * from A where A1 = 11
如果先運行事務Ⅰ，然后緊接著運行事務Ⅱ，則事務Ⅱ要等待10秒鐘（一個連接在修改數據塊時別的連接也不能查詢這個數據塊，直到解鎖。反之亦然：讀的時候不能寫和修改）。
如果把事務Ⅱ改為如下
SET TRANSACTION ISOLATION LEVEL READ UNCommitted
select * from A where A1 = 11
那么事務Ⅱ不需等待，立即執行（可以看出READ UNCommitted事務select不對數據發出共享鎖）
鎖：(這里主要講解 共享鎖 和 排他鎖 兩種經常用到的鎖)
共享鎖主要是為了共享讀（select），如果存在事務（一個或多個）擁有對表中數據（關于鎖數據的多少，視鎖的粒度而定）的共享鎖，不允許對鎖定的數據進行更新(update)（從鎖的角度講，即不允許事務獲取排他鎖，要等到所有的共享鎖都釋放掉）。反之，如果事務對數據已經具有排他鎖（只能有一個），其他的事務就不能對鎖定的數據獲取共享鎖和排他鎖（即排他鎖與共享鎖不能兼容，更多信息請查看鎖兼容性），在此特別強調一下 鎖定的數據 ，因為有的資料上講解到“一個連接寫的時候，另一個連接可以寫”，實際上寫的這種情況是各個連接的讀寫的數據不是相同的行，也就是說各個連接鎖定的數據不同。
根據以上分析，我們總結為六個字為“共享讀，排他寫”。
了解了鎖的情況之后，又涉及到一個問題。事務究竟要保持鎖多久呢?
一般來說，共享鎖的鎖定時間與事務的隔離級別有關，如果隔離級別為Read Committed的默認級別，只在讀取(select)的期間保持鎖定，即在查詢出數據以后就釋放了鎖；如果隔離級別為更高的Repeatable read或Serializable，直到事務結束才釋放鎖。另說明，如果select語句中指定了HoldLock提示，則也要等到事務結束才釋放鎖。
排他鎖直到事務結束才釋放。
做出了以上分析，現在我們可能會存在這樣的疑問，到底在執行SQL語句的時候發出什么樣的鎖呢，這就由事務的隔離級別決定了。一般情況，讀語句(select)發出共享鎖，寫語句(update,insert,delete)發出排他鎖。但是，如果這樣不能滿足我們的要求怎么辦呢，有沒有更多選擇呢，別急，SQLserver為我們提供了鎖定提示的概念。
鎖定提示對SQL語句進行特別指定，這個指定將覆蓋事務的隔離級別。下面對各個鎖定提示分別予以介紹（更多資料請查看SQLserver的聯機幫助），筆者做出了以下分類。
類型1
① READUNCOMMITTED：不發出鎖
② READCOMMITTED：發出共享鎖，保持到讀取結束
③ REPEATABLEREAD：發出共享鎖，保持到事務結束
④ SERIALIZABLE：發出共享鎖，保持到事務結束
類型2
① NOLOCK：不發出鎖。等同于READUNCOMMITTED
② HOLDLOCK：發出共享鎖，保持到事務結束。等同于SERIALIZABLE
③ XLOCK：發出排他鎖，保持到事務結束。
④ UPDLOCK：發出更新鎖，保持到事務事務結束。（更新鎖：不阻塞別的事物，允許別的事物讀數據（即更新鎖可與共享鎖兼容），但他確保自上次讀取數據后數據沒有被更新）
⑤ READPAST：發出共享鎖，但跳過鎖定行，它不會被阻塞。適用條件：提交讀的隔離級別，行級鎖，select語句中。
類型3
① ROWLOCK：行級鎖
② PAGLOCK：頁級鎖
③ TABLOCK：表鎖
④ TABLOCKX：表排他鎖
講解完鎖后，下面結合一個具體實例，具體看一下鎖的使用。
在很多系統中，經常會遇到這種情況，要保持一個編號的唯一，如會計軟件中的憑證的編號。一種編號的處理是這樣的，把表中的最大編號保存到表中，然后在這個編號上累加，形成新的編號。這個過程對并發處理要求非常高，下面我們就來模擬這個過程，看如何保持編號的唯一性。
新建一張表code來保存憑證的最大編號。字段如下：編號:bh(numeric(18,0)),憑證表名pinzheng(varchar(50))
假設表中有這樣的一條記錄：
新建一個存儲過程來生成新的憑證編號，如下：
CREATE PROCEDURE up_getbh AS
Begin Tran
Declare @numnewbh numeric(18,0)
select @numnewbh = bh FROM code WITH (UPDLOCK,ROWLOCK) where pinzheng = '會計憑證'
set @numnewbh = @numnewbh + 1
update code set bh = @numnewbh where pinzheng = '會計憑證'
print @numnewbh
Commit tran
GO
然后，打開查詢分析器，并多開幾個連接（筆者開了8個連接，模擬有8個人同時并發，讀者可以開更多的連接進行試驗），把類似以下這樣的語句復制到每個連接窗口中，
declare @i numeric(18,0)
set @i = 1
while @i = 1
Begin
if getdate() > '2004-07-22 14:23' --設定一個時間，到此時間同時執行upgetbh存儲過程
set @i = 0
end
exec up_getbh
然后，接連運行各個連接，到2004-7-22 14：23 這一刻，各個連接同時運行up_getbh。從運行結果可以看出連接順序出現18001開始個數字，并沒有重號或丟號的現象。
分析：由于up_getbh中的select語句使用了更新鎖，因更新鎖之間不能兼容，所以各個連接要等到所有其他的連接釋放掉鎖才能執行，而更新鎖的釋放要等到事務結束，這樣就不會發生號出錯的現象了。
posted on 2010-02-04 15:01
何克勤 閱讀(742)
評論(0) 編輯 收藏 所屬分類:
數據庫和SQL