數(shù)據(jù)庫--鎖
1#定義
數(shù)據(jù)庫和操作系統(tǒng)一樣，是一個多用戶使用的共享資源。當(dāng)多個用戶并發(fā)地存取數(shù)據(jù)時，在數(shù)據(jù)庫中就會產(chǎn)生多個事務(wù)同時存取同一數(shù)據(jù)的情況。若對并發(fā)操作不加控制就可能會讀取和存儲不正確的數(shù)據(jù)，破壞數(shù)據(jù)庫的一致性。
加鎖是實(shí)現(xiàn)數(shù)據(jù)庫并發(fā)控制的一個非常重要的技術(shù)。在實(shí)際應(yīng)用中經(jīng)常會遇到的與鎖相關(guān)的異常情況，當(dāng)兩個事務(wù)需要一組有沖突的鎖，而不能將事務(wù)繼續(xù)下去的話，就會出現(xiàn)死鎖，嚴(yán)重影響應(yīng)用的正常執(zhí)行。
在數(shù)據(jù)庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。
@當(dāng)數(shù)據(jù)對象被加上排它鎖時，其他的事務(wù)不能對它讀取和修改。
@加了共享鎖的數(shù)據(jù)對象可以被其他事務(wù)讀取，但不能修改。
數(shù)據(jù)庫利用這兩種基本的鎖類型來對數(shù)據(jù)庫的事務(wù)進(jìn)行并發(fā)控制。
2#悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機(jī)制（也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)）。
一個典型的倚賴數(shù)據(jù)庫的悲觀鎖調(diào)用：
select * from account where name=”Erica” for update
這條 sql 語句鎖定了 account 表中所有符合檢索條件（name=“Erica”）的記錄。本次事務(wù)提交之前（事務(wù)提交時會釋放事務(wù)過程中的鎖），外界無法修改這些記錄。
悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性。但隨之而來的就是數(shù)據(jù)庫性能的大量開銷，特別是對長事務(wù)而言，這樣的開銷往往無法承受。如一個金融系統(tǒng)，當(dāng)某個操作員讀取用戶的數(shù)據(jù)，并在讀出的用戶數(shù)據(jù)的基礎(chǔ)上進(jìn)行修改時（如更改用戶帳戶余額），如果采用悲觀鎖機(jī)制，也就意味著整個操作過程中（從操作員讀出數(shù)據(jù)、開始修改直至提交修改結(jié)果的全過程，甚至還包括操作員中途去煮咖啡的時間），數(shù)據(jù)庫記錄始終處于加鎖狀態(tài)，可以想見，如果面對幾 百上千個并發(fā)，這樣的情況將導(dǎo)致怎樣的后果。
3#樂觀鎖機(jī)制在一定程度上解決了這個問題。樂觀鎖，大多是基于數(shù)據(jù)版本（Version）記錄機(jī)制實(shí)現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個版本標(biāo)識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是通過為數(shù)據(jù)庫表增加一個 “version” 字段來實(shí)現(xiàn)讀取出數(shù)據(jù)時，將此版本號一同讀出，之后更新時，對此版本號加一。此時，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對，如果提交的數(shù)據(jù)版本號大于數(shù)據(jù)庫表當(dāng)前版本號，則予以更新，否則認(rèn)為是過期數(shù)據(jù)。
對于上面修改用戶帳戶信息的例子而言，假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個 version 字段，當(dāng)前值為 1 ；而當(dāng)前帳戶余額字段（ balance ）為 $100 。
1 操作員 A 此時將其讀出（ version=1 ），并從其帳戶余額中扣除 $50（ $100-$50 ）。
2 在操作員 A 操作的過程中，操作員 B 也讀入此用戶信息（ version=1 ），并從其帳戶余額中扣除 $20 （ $100-$20 ）。
3 操作員 A 完成了修改工作，將數(shù)據(jù)版本號加一（ version=2 ），連同帳戶扣除后余額（ balance=$50 ），提交至數(shù)據(jù)庫更新，此時由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫記錄當(dāng)前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄 version 更新為 2 。
4 操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向數(shù)據(jù)庫提交數(shù)據(jù)（ balance=$80 ），但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)，操作員 B 提交的數(shù)據(jù)版本號為 2 ，數(shù)據(jù)庫記錄當(dāng)前版本也為 2 ，不滿足 “ 提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新 “ 的樂觀鎖策略，因此，操作員 B 的提交被駁回。這樣，就避免了操作員 B 用基于version=1的舊數(shù)據(jù)修改的結(jié)果覆蓋操作員 A 的操作結(jié)果的可能。
4#死鎖
死鎖的第一種情況
一個用戶A 訪問表A(鎖住了表A),然后又訪問表B；另一個用戶B 訪問表B(鎖住了表B)，然后企圖訪問表A；這時用戶A由于用戶B已經(jīng)鎖住表B，它必須等待用戶B釋放表B才能繼續(xù)，同樣用戶B要等用戶A釋放表A才能繼續(xù)，這就死鎖就產(chǎn)生了。
解決方法：
這種死鎖比較常見，是由于程序的BUG產(chǎn)生的，除了調(diào)整的程序的邏輯沒有其它的辦法。仔細(xì)分析程序的邏輯，對于數(shù)據(jù)庫的多表操作時，盡量按照相同的順序進(jìn)行處理，盡量避免同時鎖定兩個資源，如操作A和B兩張表時，總是按先A后B的順序處理， 必須同時鎖定兩個資源時，要保證在任何時刻都應(yīng)該按照相同的順序來鎖定資源。
死鎖的第二種情況
用戶A查詢一條紀(jì)錄，然后修改該條紀(jì)錄；這時用戶B修改該條紀(jì)錄，這時用戶A的事務(wù)里鎖的性質(zhì)由查詢的共享鎖企圖上升到獨(dú)占鎖，而用戶B里的獨(dú)占鎖由于A有共享鎖存在所以必須等A釋放掉共享鎖，而A由于B的獨(dú)占鎖而無法上升的獨(dú)占鎖也就不可能釋放共享鎖，于是出現(xiàn)了死鎖。這種死鎖比較隱蔽，但在稍大點(diǎn)的項(xiàng)目中經(jīng)常發(fā)生。如在某項(xiàng)目中，頁面上的按鈕點(diǎn)擊后，沒有使按鈕立刻失效，使得用戶會多次快速點(diǎn)擊同一按鈕，這樣同一段代碼對數(shù)據(jù)庫同一條記錄進(jìn)行多次操作，很容易就出現(xiàn)這種死鎖的情況。
解決方法：
1、對于按鈕等控件，點(diǎn)擊后使其立刻失效，不讓用戶重復(fù)點(diǎn)擊，避免對同時對同一條記錄操作。
2、使用樂觀鎖進(jìn)行控制。
3、使用悲觀鎖進(jìn)行控制。
死鎖的第三種情況
如果在事務(wù)中執(zhí)行了一條不滿足條件的update語句，則執(zhí)行全表掃描，把行級鎖上升為表級鎖，多個這樣的事務(wù)執(zhí)行后，就很容易產(chǎn)生死鎖和阻塞。類似的情況還有當(dāng)表中的數(shù)據(jù)量非常龐大而索引建的過少或不合適的時候，使得經(jīng)常發(fā)生全表掃描，最終應(yīng)用系統(tǒng)會越來越慢，最終發(fā)生阻塞或死鎖。
解決方法：
SQL語句中不要使用太復(fù)雜的關(guān)聯(lián)多表的查詢；使用“執(zhí)行計劃”對SQL語句進(jìn)行分析，對于有全表掃描的SQL語句，建立相應(yīng)的索引進(jìn)行優(yōu)化。
posted on 2010-02-04 14:16
何克勤 閱讀(294)
評論(0) 編輯 收藏 所屬分類:
數(shù)據(jù)庫和SQL