1前言
數據庫大并發(fā)操作要考慮死鎖和鎖的性能問題虹蒋∧叮看到網上大多語焉不詳(尤其更新鎖），所以這里做個簡明解釋总棵，為下面描述方便鳍寂，這里用T1代表一個數據庫執(zhí)行請求，T2代表另一個請求情龄，也可以理解為T1為一個線程迄汛，T2 為另一個線程。T3,T4以此類推骤视。下面以SQL Server(2005)為例鞍爱。
共享鎖(Shared lock)。
例1：
----------------------------------------
T1:? ? select * from table (請想象它需要執(zhí)行1個小時之久专酗，后面的sql語句請都這么想象）
T2:? ? update table set column1='hello'
過程：
T1運行 （加共享鎖)
T2運行
If T1 還沒執(zhí)行完
? ? T2等......
else
? ? 鎖被釋放
? ? T2執(zhí)行
endif
T2之所以要等睹逃，是因為T2在執(zhí)行update前，試圖對table表加一個排他鎖祷肯，
而數據庫規(guī)定同一資源上不能同時共存共享鎖和排他鎖沉填。所以T2必須等T1
執(zhí)行完，釋放了共享鎖佑笋，才能加上排他鎖翼闹，然后才能開始執(zhí)行update語句。
例2：
----------------------------------------
T1:? ? select * from table
T2:? ? select * from table
這里T2不用等待T1執(zhí)行完蒋纬，而是可以馬上執(zhí)行橄碾。
分析：
T1運行，則table被加鎖颠锉，比如叫l(wèi)ockA
T2運行，再對table加一個共享鎖史汗，比如叫l(wèi)ockB琼掠。
兩個鎖是可以同時存在于同一資源上的（比如同一個表上）。這被稱為共
享鎖與共享鎖兼容停撞。這意味著共享鎖不阻止其它session同時讀資源瓷蛙，但阻
止其它session update
例3：
----------------------------------------
T1:? ? select * from table
T2:? ? select * from table
T3:? ? update table set column1='hello'
這次，T2不用等T1運行完就能運行戈毒，T3卻要等T1和T2都運行完才能運行艰猬。
因為T3必須等T1和T2的共享鎖全部釋放才能進行加排他鎖然后執(zhí)行update
操作。
例4：（死鎖的發(fā)生）
----------------------------------------
T1:
begin tran
select * from table (holdlock) (holdlock意思是加共享鎖埋市，直到事物結束才釋放)
update table set column1='hello'
T2:
begin tran
select * from table(holdlock)
update table set column1='world'
假設T1和T2同時達到select冠桃，T1對table加共享鎖，T2也對加共享鎖道宅，當
T1的select執(zhí)行完食听，準備執(zhí)行update時胸蛛，根據鎖機制，T1的共享鎖需要升
級到排他鎖才能執(zhí)行接下來的update.在升級排他鎖前樱报，必須等table上的
其它共享鎖釋放葬项，但因為holdlock這樣的共享鎖只有等事務結束后才釋放，
所以因為T2的共享鎖不釋放而導致T1等(等T2釋放共享鎖迹蛤，自己好升級成排
他鎖）民珍，同理，也因為T1的共享鎖不釋放而導致T2等盗飒。死鎖產生了嚷量。
例5：
----------------------------------------
T1:
begin tran
update table set column1='hello' where id=10
T2:
begin tran
update table set column1='world' where id=20
這種語句雖然最為常見，很多人覺得它有機會產生死鎖箩兽，但實際上要看情
況津肛，如果id是主鍵上面有索引，那么T1會一下子找到該條記錄(id=10的記
錄）汗贫，然后對該條記錄加排他鎖身坐，T2，同樣落包，一下子通過索引定位到記錄部蛇，
然后對id=20的記錄加排他鎖，這樣T1和T2各更新各的咐蝇，互不影響涯鲁。T2也不
需要等。
但如果id是普通的一列有序，沒有索引抹腿。那么當T1對id=10這一行加排他鎖后，
T2為了找到id=20旭寿，需要對全表掃描警绩，那么就會預先對表加上共享鎖或更新
鎖或排他鎖(依賴于數據庫執(zhí)行策略和方式，比如第一次執(zhí)行和第二次執(zhí)行
數據庫執(zhí)行策略就會不同）盅称。但因為T1已經為一條記錄加了排他鎖肩祥，導致
T2的全表掃描進行不下去，就導致T2等待缩膝。
死鎖怎么解決呢混狠？一種辦法是，如下：
例6：
----------------------------------------
T1:
begin tran
select * from table(xlock) (xlock意思是直接對表加排他鎖)
update table set column1='hello'
T2:
begin tran
select * from table(xlock)
update table set column1='world'
這樣疾层，當T1的select 執(zhí)行時将饺，直接對表加上了排他鎖，T2在執(zhí)行select時，就需要等T1事物完全執(zhí)行完才能執(zhí)行俯逾。排除了死鎖發(fā)生贸桶。
但當第三個user過來想執(zhí)行一個查詢語句時，也因為排他鎖的存在而不得不等待桌肴，第四個皇筛、第五個user也會因此而等待。在大并發(fā)
情況下坠七，讓大家等待顯得性能就太友好了水醋，所以，這里引入了更新鎖彪置。
更新鎖(Update lock)
為解決死鎖拄踪，引入更新鎖。
例7：
----------------------------------------
T1:
begin tran
select * from table(updlock) (加更新鎖)
update table set column1='hello'
T2:
begin tran
select * from table(updlock)
update table set column1='world'
更新鎖的意思是：“我現在只想讀拳魁，你們別人也可以讀惶桐，但我將來可能會做更新操作，我已經獲取了從共享鎖（用來讀）到排他鎖
（用來更新）的資格”潘懊。一個事物只能有一個更新鎖獲此資格姚糊。
T1執(zhí)行select，加更新鎖授舟。
T2運行救恨，準備加更新鎖，但發(fā)現已經有一個更新鎖在那兒了释树，只好等肠槽。
當后來有user3、user4...需要查詢table表中的數據時奢啥，并不會因為T1的select在執(zhí)行就被阻塞秸仙，照樣能查詢，相比起例6桩盲，這提高
了效率筋栋。
例8:
----------------------------------------
T1:? ? select * from table(updlock)? ? (加更新鎖）
T2:? ? select * from table(updlock)? ? (等待，直到T1釋放更新鎖正驻，因為同一時間不能在同一資源上有兩個更新鎖）
T3:? ? select * from table (加共享鎖，但不用等updlock釋放抢腐，就可以讀）
這個例子是說明：共享鎖和更新鎖可以同時在同一個資源上姑曙。這被稱為共享鎖和更新鎖是兼容的。
例9:
----------------------------------------
T1:
begin
select * from table(updlock)? ? ? (加更新鎖）
update table set column1='hello'? (重點：這里T1做update時迈倍，不需要等T2釋放什么伤靠，而是直接把更新鎖升級為排他鎖，然后執(zhí)行update)
T2:
begin
select * from table? ? ? ? ? ? ? (T1加的更新鎖不影響T2讀取）
update table set column1='world'? (T2的update需要等T1的update做完才能執(zhí)行)
我們以這個例子來加深更新鎖的理解宴合，
第一種情況：T1先達焕梅，T2緊接到達；在這種情況中卦洽，T1先對表加更新鎖贞言，T2對表加共享鎖，假設T2的select先執(zhí)行完阀蒂，準備執(zhí)行update该窗，
發(fā)現已有更新鎖存在，T2等蚤霞。T1執(zhí)行這時才執(zhí)行完select酗失，準備執(zhí)行update，更新鎖升級為排他鎖昧绣，然后執(zhí)行update规肴，執(zhí)行完成，事務
結束夜畴，釋放鎖拖刃，T2才輪到執(zhí)行update。
第二種情況：T2先達斩启，T1緊接達序调；在這種情況，T2先對表加共享鎖兔簇，T1達后发绢，T1對表加更新鎖，假設T2 select先結束垄琐，準備
update边酒，發(fā)現已有更新鎖，則等待狸窘，后面步驟就跟第一種情況一樣了墩朦。
這個例子是說明：排他鎖與更新鎖是不兼容的，它們不能同時加在同一子資源上翻擒。
排他鎖（獨占鎖氓涣，Exclusive Locks)
這個簡單，即其它事務既不能讀陋气，又不能改排他鎖鎖定的資源劳吠。
例10
T1:? ? update table set column1='hello' where id<1000
T2:? ? update table set column1='world' where id>1000
假設T1先達，T2隨后至巩趁，這個過程中T1會對id<1000的記錄施加排他鎖.但不會阻塞T2的update痒玩。
例11 (假設id都是自增長且連續(xù)的）
T1:? ? update table set column1='hello' where id<1000
T2:? ? update table set column1='world' where id>900
如同例10，T1先達，T2立刻也到蠢古，T1加的排他鎖會阻塞T2的update.
意向鎖(Intent Locks)
意向鎖就是說在屋（比如代表一個表）門口設置一個標識奴曙，說明屋子里有人（比如代表某些記錄）被鎖住了。另一個人想知道屋子
里是否有人被鎖草讶，不用進屋子里一個一個的去查洽糟，直接看門口標識就行了。
當一個表中的某一行被加上排他鎖后到涂，該表就不能再被加表鎖脊框。數據庫程序如何知道該表不能被加表鎖？一種方式是逐條的判斷該
表的每一條記錄是否已經有排他鎖践啄，另一種方式是直接在表這一層級檢查表本身是否有意向鎖浇雹，不需要逐條判斷。顯然后者效率高屿讽。
例12：
----------------------------------------
T1:? ? begin tran
? ? ? select * from table (xlock) where id=10? --意思是對id=10這一行強加排他鎖
T2:? ? begin tran
? ? ? select * from table (tablock)? ? --意思是要加表級鎖
假設T1先執(zhí)行昭灵，T2后執(zhí)行，T2執(zhí)行時伐谈，欲加表鎖烂完，為判斷是否可以加表鎖，數據庫系統(tǒng)要逐條判斷table表每行記錄是否已有排他鎖诵棵，
如果發(fā)現其中一行已經有排他鎖了抠蚣，就不允許再加表鎖了。只是這樣逐條判斷效率太低了履澳。
實際上嘶窄，數據庫系統(tǒng)不是這樣工作的。當T1的select執(zhí)行時距贷，系統(tǒng)對表table的id=10的這一行加了排他鎖柄冲，還同時悄悄的對整個表
加了意向排他鎖(IX)，當T2執(zhí)行表鎖時忠蝗，只需要看到這個表已經有意向排他鎖存在现横，就直接等待，而不需要逐條檢查資源了阁最。
例13：
----------------------------------------
T1:? ? begin tran
? ? ? update table set column1='hello' where id=1
T2:? ? begin tran
? ? ? update table set column1='world' where id=1
這個例子和上面的例子實際效果相同戒祠，T1執(zhí)行，系統(tǒng)對table同時對行家排他鎖速种、對頁加意向排他鎖姜盈、對表加意向排他鎖。
計劃鎖(Schema Locks)
例14：
----------------------------------------
alter table .... (加schema locks哟旗，稱之為Schema modification (Sch-M) locks
DDL語句都會加Sch-M鎖
該鎖不允許任何其它session連接該表。連都連不了這個表了，當然更不用說想對該表執(zhí)行什么sql語句了闸餐。
例15:
----------------------------------------
用jdbc向數據庫發(fā)送了一條新的sql語句饱亮，數據庫要先對之進行編譯，在編譯期間舍沙，也會加鎖近上，稱之為：Schema stability (Sch-S) locks
select * from tableA
編譯這條語句過程中，其它session可以對表tableA做任何操作(update,delete拂铡，加排他鎖等等）壹无，但不能做DDL(比如alter table)操作。
Bulk Update Locks 主要在批量導數據時用（比如用類似于oracle中的imp/exp的bcp命令）感帅。不難理解斗锭，程序員往往也不需要關心，不贅述了失球。
如何加鎖，何時加鎖实苞，加什么鎖豺撑，你可以通過hint手工強行指定，但大多是數據庫系統(tǒng)自動決定的黔牵。這就是為什么我們可以不懂鎖也可
以高高興興的寫SQL聪轿。
例15:
----------------------------------------
T1:? ? begin tran
? ? ? update table set column1='hello' where id=1
T2:? ? SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED? -- 事物隔離級別為允許臟讀
? ? ? go
? ? ? select * from table where id=1
這里，T2的select可以查出結果猾浦。如果事物隔離級別不設為臟讀陆错，則T2會等T1事物執(zhí)行完才能讀出結果。
數據庫如何自動加鎖的跃巡？
1) T1執(zhí)行危号，數據庫自動加排他鎖
2) T2執(zhí)行，數據庫發(fā)現事物隔離級別允許臟讀素邪，便不加共享鎖外莲。不加共享鎖，則不會與已有的排他鎖沖突兔朦，所以可以臟讀偷线。
例16:
----------------------------------------
T1:? ? begin tran
? ? ? update table set column1='hello' where id=1
T2:? ? select * from table where id=1 --為指定隔離級別，則使用系統(tǒng)默認隔離級別沽甥，它不允許臟讀
如果事物級別不設為臟讀声邦，則：
1) T1執(zhí)行，數據庫自動加排他鎖
2) T2執(zhí)行摆舟，數據庫發(fā)現事物隔離級別不允許臟讀亥曹，便準備為此次select過程加共享鎖邓了，但發(fā)現加不上，因為已經有排他鎖了媳瞪，所以就
? 等啊等骗炉。直到T1執(zhí)行完，釋放了排他鎖蛇受，T2才加上了共享鎖句葵，然后開始讀....
鎖的粒度就是指鎖的生效范圍，就是說是行鎖兢仰，還是頁鎖乍丈，還是整表鎖. 鎖的粒度同樣既可以由數據庫自動管理，也可以通過手工指定hint來管理把将。
例17：
----------------------------------------
T1:? ? select * from table (paglock)
T2:? ? update table set column1='hello' where id>10
T1執(zhí)行時轻专，會先對第一頁加鎖，讀完第一頁后秸弛，釋放鎖铭若，再對第二頁加鎖，依此類推递览。假設前10行記錄恰好是一頁(當然叼屠，一般不可能
一頁只有10行記錄），那么T1執(zhí)行到第一頁查詢時绞铃，并不會阻塞T2的更新镜雨。
例18：
----------------------------------------
T1:? ? select * from table (rowlock)
T2:? ? update table set column1='hello' where id=10
T1執(zhí)行時，對每行加共享鎖儿捧，讀取荚坞，然后釋放，再對下一行加鎖;T2執(zhí)行時菲盾，會對id=10的那一行試圖加鎖颓影，只要該行沒有被T1加上行鎖，
T2就可以順利執(zhí)行update操作懒鉴。
例19：
----------------------------------------
T1:? ? select * from table (tablock)
T2:? ? update table set column1='hello' where id = 10
T1執(zhí)行诡挂，對整個表加共享鎖. T1必須完全查詢完，T2才可以允許加鎖临谱，并開始更新璃俗。
以上3例是手工指定鎖的粒度，也可以通過設定事物隔離級別悉默，讓數據庫自動設置鎖的粒度城豁。不同的事物隔離級別，數據庫會有不同的
加鎖策略（比如加什么類型的鎖抄课，加什么粒度的鎖）唱星。具體請查聯機手冊雳旅。
手工指定的鎖優(yōu)先，
例20:
----------------------------------------
T1:? ? GO
? ? ? SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
? ? ? GO
? ? ? BEGIN TRANSACTION
? ? ? SELECT * FROM table (NOLOCK)
? ? ? GO
T2:? ? update table set column1='hello' where id=10
T1是事物隔離級別為最高級间聊，串行鎖岭辣，數據庫系統(tǒng)本應對后面的select語句自動加表級鎖，但因為手工指定了NOLOCK甸饱，所以該select
語句不會加任何鎖，所以T2也就不會有任何阻塞仑濒。
1) holdlock 對表加共享鎖叹话，且事物不完成，共享鎖不釋放墩瞳。
2) tablock? 對表加共享鎖驼壶，只要statement不完成，共享鎖不釋放喉酌。
? 與holdlock區(qū)別热凹，見下例：
? 例21
? ----------------------------------------
? T1:
? begin tran
? select * from table (tablock)
? T2:
? begin tran
? update table set column1='hello' where id = 10
? T1執(zhí)行完select，就會釋放共享鎖泪电，然后T2就可以執(zhí)行update. 此之謂tablock. 下面我們看holdlock
? 例22
? ----------------------------------------
? T1:
? begin tran
? select * from table (holdlock)
? T2:
? begin tran
? update table set column1='hello' where id = 10
? T1執(zhí)行完select般妙，共享鎖仍然不會釋放，仍然會被hold(持有）相速，T2也因此必須等待而不能update. 當T1最后執(zhí)行了commit或
? rollback說明這一個事物結束了碟渺，T2才取得執(zhí)行權。
3) TABLOCKX 對表加排他鎖
? 例23：
? ----------------------------------------
? T1:? ? select * from table(tablockx) (強行加排他鎖）
? 其它session就無法對這個表進行讀和更新了突诬，除非T1執(zhí)行完了苫拍，就會自動釋放排他鎖。
? 例24：
? ----------------------------------------
? T1:? ? begin tran
? ? ? ? ? select * from table(tablockx)
? 這次旺隙，單單select執(zhí)行完還不行绒极，必須整個事物完成（執(zhí)行了commit或rollback后）才會釋放排他鎖。
4) xlock 加排他鎖
? 那它跟tablockx有何區(qū)別呢蔬捷？
? 它可以這樣用垄提，
? 例25:
? ----------------------------------------
? select * from table(xlock paglock) 對page加排他鎖
? 而TABLELOCX不能這么用。
? xlock還可這么用：select * from table(xlock tablock) 效果等同于select * from table(tablockx)
例26
SET LOCK_TIMEOUT 4000 用來設置鎖等待時間抠刺，單位是毫秒塔淤，4000意味著等待
4秒可以用select @@LOCK_TIMEOUT查看當前session的鎖超時設置。-1 意味著
永遠等待速妖。
T1: begin tran
? ? udpate table set column1='hello' where id = 10
T2: set lock_timeout 4000
? ? select * from table wehre id = 10
T2執(zhí)行時高蜂，會等待T1釋放排他鎖，等了4秒鐘罕容，如果T1還沒有釋放排他鎖备恤，T2就會拋出異常： Lock request time out period exceeded.
| Requested mode? ? ? ? ? ? ? ? ? ? | IS? | S? | U? | IX? | SIX | X? |
| Intent shared (IS)? ? ? ? ? ? ? ? | Yes | Yes | Yes | Yes | Yes | No |
| Shared (S)? ? ? ? ? ? ? ? ? ? ? ? | Yes | Yes | Yes | No? | No? | No |
| Update (U)? ? ? ? ? ? ? ? ? ? ? ? | Yes | Yes | No? | No? | No? | No |
| Intent exclusive (IX)? ? ? ? ? ? ? | Yes | No? | No? | Yes | No? | No |
| Shared with intent exclusive (SIX) | Yes | No? | No? | No? | No? | No |
| Exclusive (X)? ? ? ? ? ? ? ? ? ? ? | No? | No? | No? | No? | No? | No |
悲觀鎖：利用數據庫本身的鎖機制實現稿饰。通過上面對數據庫鎖的了解，可以根據具體業(yè)務情況綜合使用事務隔離級別與合理的手工指定鎖的方式比如降低鎖的粒度等減少并發(fā)等待露泊。
樂觀鎖：利用程序處理并發(fā)喉镰。原理都比較好理解，基本一看即懂惭笑。方式大概有以下3種
對記錄加版本號.
對記錄加時間戳.
對將要更新的數據進行提前讀取侣姆、事后對比。
不論是數據庫系統(tǒng)本身的鎖機制沉噩，還是樂觀鎖這種業(yè)務數據級別上的鎖機制捺宗，本質上都是對狀態(tài)位的讀、寫川蒙、判斷蚜厉。
