事務：保持邏輯數(shù)據(jù)一致性與可恢復性，必不可少的利器。

鎖：多用戶訪問同一數(shù)據(jù)庫資源時，對訪問的先后次序權限管理的一種機制，沒有他事務或許將會一塌糊涂，不能保證數(shù)據(jù)的安全正確讀寫。

死鎖：是數(shù)據(jù)庫性能的重量級殺手之一，而死鎖卻是不同事務之間搶占數(shù)據(jù)資源造成的。

不懂的聽上去，挺神奇的，懂的感覺我在扯淡，下面帶你好好領略下他們的風采，嗅査下他們的狂騷。。

用華仔無間道中的一句來給你詮釋下：去不了終點，回到原點。

舉例說明：

在一個事務中，你寫啦2條sql語句，一條是修改訂單表狀態(tài),一條是修改庫存表庫存-1 。 如果在修改訂單表狀態(tài)的時候出錯，事務能夠回滾，數(shù)據(jù)將恢復到沒修改之前的數(shù)據(jù)狀態(tài)，下面的修改庫存也就不執(zhí)行，這樣確保你關系邏輯的一致，安全。。

事務就是這個樣子，倔脾氣，要么全部執(zhí)行，要么全部不執(zhí)行，回到原數(shù)據(jù)狀態(tài)。

書面解釋：事務具有原子性，一致性，隔離性，持久性。

• 原子性：事務必須是一個自動工作的單元，要么全部執(zhí)行，要么全部不執(zhí)行。
• 一致性：事務結束的時候，所有的內部數(shù)據(jù)都是正確的。
• 隔離性：并發(fā)多個事務時，各個事務不干涉內部數(shù)據(jù)，處理的都是另外一個事務處理之前或之后的數(shù)據(jù)。
• 持久性：事務提交之后，數(shù)據(jù)是永久性的，不可再回滾。

然而在SQL Server中事務被分為3類常見的事務：

• 自動提交事務：是SQL Server默認的一種事務模式，每條Sql語句都被看成一個事務進行處理，你應該沒有見過，一條Update 修改2個字段的語句，只修該了1個字段而另外一個字段沒有修改。。
• 顯式事務：T-sql標明，由Begin Transaction開啟事務開始，由Commit Transaction 提交事務、Rollback Transaction 回滾事務結束。
• 隱式事務：使用Set IMPLICIT_TRANSACTIONS ON 將將隱式事務模式打開，不用Begin Transaction開啟事務，當一個事務結束，這個模式會自動啟用下一個事務，只用Commit Transaction 提交事務、Rollback Transaction 回滾事務即可。

常用語句就四個。

• Begin Transaction：標記事務開始。
• Commit Transaction：事務已經成功執(zhí)行，數(shù)據(jù)已經處理妥當。
• Rollback Transaction：數(shù)據(jù)處理過程中出錯，回滾到沒有處理之前的數(shù)據(jù)狀態(tài)，或回滾到事務內部的保存點。
• Save Transaction：事務內部設置的保存點，就是事務可以不全部回滾，只回滾到這里，保證事務內部不出錯的前提下。

上面的都是心法，下面的給你來個招式，要看仔細啦。

 1 ---開啟事務 2 begin tran 3 --錯誤撲捉機制，看好啦，這里也有的。并且可以嵌套。 4 begin try   5    --語句正確 6    insert into lives (Eat,Play,Numb) values ('豬肉','足球',1) 7    --Numb為int類型，出錯 8    insert into lives (Eat,Play,Numb) values ('豬肉','足球','abc') 9    --語句正確10    insert into lives (Eat,Play,Numb) values ('狗肉','籃球',2)11 end try12 begin catch13    select Error_number() as ErrorNumber,  --錯誤代碼14           Error_severity() as ErrorSeverity,  --錯誤嚴重級別，級別小于10 try catch 捕獲不到15           Error_state() as ErrorState ,  --錯誤狀態(tài)碼16           Error_PRocedure() as ErrorProcedure , --出現(xiàn)錯誤的存儲過程或觸發(fā)器的名稱。17           Error_line() as ErrorLine,  --發(fā)生錯誤的行號18           Error_message() as ErrorMessage  --錯誤的具體信息19    if(@@trancount>0) --全局變量@@trancount，事務開啟此值+1，他用來判斷是有開啟事務20       rollback tran  ---由于出錯，這里回滾到開始，第一條語句也沒有插入成功。21 end catch22 if(@@trancount>0)23 commit tran  --如果成功Lives表中，將會有3條數(shù)據(jù)。24 25 --表本身為空表，ID ,Numb為int 類型，其它為nvarchar類型26 select * from lives

---開啟事務begin tran--錯誤撲捉機制，看好啦，這里也有的。并且可以嵌套。begin try       --語句正確   insert into lives (Eat,Play,Numb) values ('豬肉','足球',1)       --加入保存點   save tran pigOneIn   --Numb為int類型，出錯   insert into lives (Eat,Play,Numb) values ('豬肉','足球',2)   --語句正確   insert into lives (Eat,Play,Numb) values ('狗肉','籃球',3)end trybegin catch   select Error_number() as ErrorNumber,  --錯誤代碼          Error_severity() as ErrorSeverity,  --錯誤嚴重級別，級別小于10 try catch 捕獲不到          Error_state() as ErrorState ,  --錯誤狀態(tài)碼          Error_Procedure() as ErrorProcedure , --出現(xiàn)錯誤的存儲過程或觸發(fā)器的名稱。          Error_line() as ErrorLine,  --發(fā)生錯誤的行號          Error_message() as ErrorMessage  --錯誤的具體信息   if(@@trancount>0) --全局變量@@trancount，事務開啟此值+1，他用來判斷是有開啟事務      rollback tran   ---由于出錯，這里回滾事務到原點，第一條語句也沒有插入成功。end catchif(@@trancount>0)rollback tran pigOneIn --如果成功Lives表中，將會有3條數(shù)據(jù)。--表本身為空表，ID ,Numb為int 類型，其它為nvarchar類型select * from lives

設置 xact_abort on/off , 指定是否回滾當前事務，為on時如果當前sql出錯，回滾整個事務，為off時如果sql出錯回滾當前sql語句，其它語句照常運行讀寫數(shù)據(jù)庫。

需要注意的時：xact_abort只對運行時出現(xiàn)的錯誤有用，如果sql語句存在編譯時錯誤，那么他就失靈啦。

delete lives  --清空數(shù)據(jù)set xact_abort offbegin tran     --語句正確   insert into lives (Eat,Play,Numb) values ('豬肉','足球',1)      --Numb為int類型，出錯,如果1234..那個大數(shù)據(jù)換成'132dsaf' xact_abort將失效   insert into lives (Eat,Play,Numb) values ('豬肉','足球',12345646879783213)   --語句正確   insert into lives (Eat,Play,Numb) values ('狗肉','籃球',3)commit transelect * from lives

為on時，結果集為空，因為運行是數(shù)據(jù)過大溢出出錯，回滾整個事務。

跟著做：打開兩個查詢窗口，把下面的語句，分別放入2個查詢窗口，在5秒內運行2個事務模塊。

begin tran   update lives set play='羽毛球'  waitfor delay '0:0:5'    update dbo.Earth set Animal='老虎' commit tran

begin tran   update Earth set Animal='老虎'   waitfor  delay '0:0:5' --等待5秒執(zhí)行下面的語句  update lives set play='羽毛球'commit transelect * from livesselect * from Earth

為什么呢，下面我們看看鎖，什么是鎖。

在多用戶都用事務同時訪問同一個數(shù)據(jù)資源的情況下，就會造成以下幾種數(shù)據(jù)錯誤。

• 更新丟失：多個用戶同時對一個數(shù)據(jù)資源進行更新，必定會產生被覆蓋的數(shù)據(jù)，造成數(shù)據(jù)讀寫異常。
• 不可重復讀：如果一個用戶在一個事務中多次讀取一條數(shù)據(jù)，而另外一個用戶則同時更新啦這條數(shù)據(jù)，造成第一個用戶多次讀取數(shù)據(jù)不一致。
• 臟讀：第一個事務讀取第二個事務正在更新的數(shù)據(jù)表，如果第二個事務還沒有更新完成，那么第一個事務讀取的數(shù)據(jù)將是一半為更新過的，一半還沒更新過的數(shù)據(jù)，這樣的數(shù)據(jù)毫無意義。
• 幻讀：第一個事務讀取一個結果集后，第二個事務，對這個結果集經行增刪操作，然而第一個事務中再次對這個結果集進行查詢時，數(shù)據(jù)發(fā)現(xiàn)丟失或新增。

然而鎖定，就是為解決這些問題所生的，他的存在使得一個事務對他自己的數(shù)據(jù)塊進行操作的時候，而另外一個事務則不能插足這些數(shù)據(jù)塊。這就是所謂的鎖定。

鎖定從數(shù)據(jù)庫系統(tǒng)的角度大致可以分為6種：

• 共享鎖（S）：還可以叫他讀鎖。可以并發(fā)讀取數(shù)據(jù)，但不能修改數(shù)據(jù)。也就是說當數(shù)據(jù)資源上存在共享鎖的時候，所有的事務都不能對這個資源進行修改，直到數(shù)據(jù)讀取完成，共享鎖釋放。
• 排它鎖（X）：還可以叫他獨占鎖、寫鎖。就是如果你對數(shù)據(jù)資源進行增刪改操作時，不允許其它任何事務操作這塊資源，直到排它鎖被釋放，防止同時對同一資源進行多重操作。
• 更新鎖（U）：防止出現(xiàn)死鎖的鎖模式，兩個事務對一個數(shù)據(jù)資源進行先讀取在修改的情況下，使用共享鎖和排它鎖有時會出現(xiàn)死鎖現(xiàn)象，而使用更新鎖則可以避免死鎖的出現(xiàn)。資源的更新鎖一次只能分配給一個事務，如果需要對資源進行修改，更新鎖會變成排他鎖，否則變?yōu)楣蚕礞i。
• 意向鎖：SQL Server需要在層次結構中的底層資源上（如行，列）獲取共享鎖，排它鎖，更新鎖。例如表級放置了意向共享鎖，就表示事務要對表的頁或行上使用共享鎖。在表的某一行上上放置意向鎖，可以防止其它事務獲取其它不兼容的的鎖。意向鎖可以提高性能，因為數(shù)據(jù)引擎不需要檢測資源的每一列每一行，就能判斷是否可以獲取到該資源的兼容鎖。意向鎖包括三種類型：意向共享鎖（IS），意向排他鎖（IX），意向排他共享鎖（SIX）。
• 架構鎖：防止修改表結構時，并發(fā)訪問的鎖。
• 大容量更新鎖：允許多個線程將大容量數(shù)據(jù)并發(fā)的插入到同一個表中，在加載的同時，不允許其它進程訪問該表。

這些鎖之間的相互兼容性，也就是，是否可以同時存在。

鎖兼容性具體參見：http://msdn.microsoft.com/zh-cn/library/ms186396.aspx

鎖粒度和層次結構參見：http://msdn.microsoft.com/zh-cn/library/ms189849(v=sql.105).aspx

什么是死鎖，為什么會產生死鎖。我用 “事務把死鎖給整出來啦” 標題下的兩個事務產生的死鎖來解釋應該會更加生動形象點。

例子是這樣的：

第一個事務（稱為A）：先更新lives表 --->>停頓5秒---->>更新earth表

第二個事務（稱為B）：先更新earth表--->>停頓5秒---->>更新lives表

先執(zhí)行事務A----5秒之內---執(zhí)行事務B，出現(xiàn)死鎖現(xiàn)象。

過程是這樣子的：

1. A更新lives表，請求lives的排他鎖，成功。
2. B更新earth表，請求earth的排他鎖，成功。
3. 5秒過后
4. A更新earth，請求earth的排它鎖，由于B占用著earth的排它鎖，等待。
5. B更新lives，請求lives的排它鎖，由于A占用著lives的排它鎖，等待。

這樣相互等待對方釋放資源，造成資源讀寫擁擠堵塞的情況，就被稱為死鎖現(xiàn)象，也叫做阻塞。而為什么會產生，上例就列舉出來啦。

然而數(shù)據(jù)庫并沒有出現(xiàn)無限等待的情況，是因為數(shù)據(jù)庫搜索引擎會定期檢測這種狀況，一旦發(fā)現(xiàn)有情況，立馬選擇一個事務作為犧牲品。犧牲的事務，將會回滾數(shù)據(jù)。有點像兩個人在過獨木橋，兩個無腦的人都走在啦獨木橋中間，如果不落水，必定要有一個人給退回來。這種相互等待的過程，是一種耗時耗資源的現(xiàn)象，所以能避則避。

哪個人會被退回來，作為犧牲品，這個我們是可以控制的。控制語法：

set deadlock_priority  <級別>

死鎖處理的優(yōu)先級別為 low<normal<high，不指定的情況下默認為normal，犧牲品為隨機。如果指定，犧牲品為級別低的。

還可以使用數(shù)字來處理標識級別：-10到-5為low，-5為normal，-5到10為high。

死鎖耗時耗資源，然而在大型數(shù)據(jù)庫中，高并發(fā)帶來的死鎖是不可避免的，所以我們只能讓其變的更少。

1. 按照同一順序訪問數(shù)據(jù)庫資源，上述例子就不會發(fā)生死鎖啦
2. 保持是事務的簡短，盡量不要讓一個事務處理過于復雜的讀寫操作。事務過于復雜，占用資源會增多，處理時間增長，容易與其它事務沖突，提升死鎖概率。
3. 盡量不要在事務中要求用戶響應，比如修改新增數(shù)據(jù)之后在完成整個事務的提交，這樣延長事務占用資源的時間，也會提升死鎖概率。
4. 盡量減少數(shù)據(jù)庫的并發(fā)量。
5. 盡可能使用分區(qū)表，分區(qū)視圖，把數(shù)據(jù)放置在不同的磁盤和文件組中，分散訪問保存在不同分區(qū)的數(shù)據(jù)，減少因為表中放置鎖而造成的其它事務長時間等待。