一,事務(wù)的4個基本特征

Atomic（原子性）：
事務(wù)中包含的操作被看做一個邏輯單元，這個邏輯單元中的操作要
么全部成功，要么全部失敗。

Consistency（一致性）：
只有合法的數(shù)據(jù)可以被寫入數(shù)據(jù)庫，否則事務(wù)應(yīng)該將其回滾到最初
狀態(tài)。

Isolation（隔離性）：
事務(wù)允許多個用戶對同一個數(shù)據(jù)進(jìn)行并發(fā)訪問，而不破壞數(shù)據(jù)的正
確性和完整性。同時，并行事務(wù)的修改必須與其他并行事務(wù)的修改
相互獨立。

Durability（持久性）：
事務(wù)結(jié)束后，事務(wù)處理的結(jié)果必須能夠得到固化。

以上屬于廢話

二,為什么需要對事務(wù)并發(fā)控制

如果不對事務(wù)進(jìn)行并發(fā)控制，我們看看數(shù)據(jù)庫并發(fā)操作是會有那些異常情形

更新丟失Lost update：
兩個事務(wù)都同時更新一行數(shù)據(jù)，但是第二個事務(wù)卻中途失敗退出，
導(dǎo)致對數(shù)據(jù)的兩個修改都失效了。

臟讀Dirty Reads：
一個事務(wù)開始讀取了某行數(shù)據(jù)，但是另外一個事務(wù)已經(jīng)更新了此數(shù)
據(jù)但沒有能夠及時提交。這是相當(dāng)危險的，因為很可能所有的操作
都被回滾。

不可重復(fù)讀Non-repeatable Reads：
一個事務(wù)對同一行數(shù)據(jù)重復(fù)讀取兩次，但是卻得到了不同的結(jié)果。

二次更新問題Second lost updates problem：
無法重復(fù)讀取的特例。有兩個并發(fā)事務(wù)同時讀取同一行數(shù)據(jù)，然后其
中一個對它進(jìn)行修改提交，而另一個也進(jìn)行了修改提交。這就會造成
第一次寫操作失效。

不可重復(fù)讀Phantom Reads：
事務(wù)在操作過程中進(jìn)行兩次查詢，第二次查詢的結(jié)果包含了第一次查
詢中未出現(xiàn)的數(shù)據(jù)（這里并不要求兩次查詢的SQL語句相同）。這是
因為在兩次查詢過程中有另外一個事務(wù)插入數(shù)據(jù)造成的。

三, 數(shù)據(jù)庫的隔離級別

為了兼顧并發(fā)效率和異常控制，在標(biāo)準(zhǔn)SQL規(guī)范中，定義了4個事務(wù)隔
離級別，（ORACLE和SQLSERER對標(biāo)準(zhǔn)隔離級別有不同的實現(xiàn) ）

事務(wù)準(zhǔn)備接受不一致數(shù)據(jù)的級別稱為隔離級別。隔離級別是一個事務(wù)必須與其它事務(wù)進(jìn)行隔離的程度。較低的隔離級別可以增加并發(fā)，但代價是降低數(shù)據(jù)的正確性。相反，較高的隔離級別可以確保數(shù)據(jù)的正確性，但可能對并發(fā)產(chǎn)生負(fù)面影響。應(yīng)用程序要求的隔離級別確定了所使用的鎖定行為：

Read Uncommitted：
直譯就是"讀未提交",意思就是即使一個更新語句沒有提交,但是別
的事務(wù)可以讀到這個改變.這是很不安全的.

Read Committed：
直譯就是"讀提交",意思就是語句提交以后即執(zhí)行了COMMIT以后
別的事務(wù)就能讀到這個改變.

Repeatable Read：
直譯就是"可以重復(fù)讀",這是說在同一個事務(wù)里面先后執(zhí)行同一個
查詢語句的時候,得到的結(jié)果是一樣的.

Serializable:
直譯就是"序列化",意思是說這個事務(wù)執(zhí)行的時候不允許別的事務(wù)
并發(fā)執(zhí)行.

四，隔離級別對并發(fā)的控制

下表是各隔離級別對各種異常的控制能力。

?	LU	DR	NRR	SLU	PR
RU	Y	Y	Y	Y	Y
RC	N	N	Y	Y	Y
RR	N	N	N	N	Y
S	N	N	N	N	N

?

?

?

?

?

?

?

?

?

(注：LU：丟失更新；DR：臟讀；NRR：非重復(fù)讀；SLU：二類丟失更新；PR：幻像讀)

順便舉一小例。

MS_SQL:
--事務(wù)一
set transaction isolation level serializable
begin tran
insert into test values('xxx')

--事務(wù)二
set transaction isolation level read committed
begin tran
select * from test

--事務(wù)三
set transaction isolation level read uncommitted
begin tran
select * from test

在查詢分析器中執(zhí)行事務(wù)一后，分別執(zhí)行事務(wù)二，和三。結(jié)果是事務(wù)二會等待，而事務(wù)三則會執(zhí)行。

ORACLE：
--事務(wù)一
set transaction isolation level serializable;
insert into test values('xxx');
select * from test;

--事務(wù)二
set transaction isolation level read committed--ORACLE默認(rèn)級別
select * from test

執(zhí)行事務(wù)一后，執(zhí)行事務(wù)二。結(jié)果是事務(wù)二只讀出原有的數(shù)據(jù)，無視事務(wù)一的插入操作。

讀者是否發(fā)現(xiàn)MS_SQL和ORACLE對并發(fā)控制的處理有所不同呢？

五,鎖

下表是鎖的兼容或沖突情形。

?	現(xiàn)有	S	U	X
申請	?	?	?	?
S	?	Y	Y	N
U	?	Y	N	N
X	?	N	N	N

?

?

?

?

?

?

?

?

?

oracle:

?

??

?

六，隔離級別與鎖

隔離級別越高越能保證數(shù)據(jù)完整性和一致性，但是對并發(fā)性能影響也越大。對于多數(shù)應(yīng)用程序，可以優(yōu)先考慮把數(shù)據(jù)庫系統(tǒng)隔離級別設(shè)為Read Committed ，它能夠避免臟讀取而且具有較好并發(fā)性能。盡管它會導(dǎo)致不可重復(fù)讀、虛讀和第二類丟失更新這些并發(fā)問題，在可能出現(xiàn)這類問題的個別場合，可以由應(yīng)用程序采用悲觀鎖或樂觀鎖來控制 。

鎖（Lock） 是在多用戶環(huán)境下對資源訪問的一種限制。機(jī)制當(dāng)對一個數(shù)據(jù)源加鎖后，此數(shù)據(jù)源就有了一定的訪問限制。我們就稱對此數(shù)據(jù)源進(jìn)行了“鎖定”。在SQL Server中，可以對以下的對象進(jìn)行鎖定：

數(shù)據(jù)行（Row）：數(shù)據(jù)頁中的單行數(shù)據(jù)；
索引行（Key）：索引頁中的單行數(shù)據(jù)，即索引的鍵值；
頁（Page）：頁是SQL Server 存取數(shù)據(jù)的基本單位，其大小為8KB；
盤區(qū)（Extent）：一個盤區(qū)由8 個連續(xù)的頁組成；
表（Table）；
數(shù)據(jù)庫（Database）。

在SQL Server 中，鎖有兩種分類方法。
（1） 從數(shù)據(jù)庫系統(tǒng)的角度來看
鎖分為以下三種類型：

1.獨占鎖（Exclusive Lock）
獨占鎖鎖定的資源只允許進(jìn)行鎖定操作的程序使用，其它任何對它的操作均不會被接受。執(zhí)行數(shù)據(jù)更新命令，即INSERT、 UPDATE 或DELETE 命令時，SQL Server 會自動使用獨占鎖。但當(dāng)對象上有其它鎖存在時，無法對其加獨占鎖。獨占鎖一直到事務(wù)結(jié)束才能被釋放。
2.共享鎖（Shared Lock）
共享鎖鎖定的資源可以被其它用戶讀取，但其它用戶不能修改它。在SELECT 命令執(zhí)行時，SQL Server 通常會對對象進(jìn)行共享鎖鎖定。通常加共享鎖的數(shù)據(jù)頁被讀取完畢后，共享鎖就會立即被釋放。
3.更新鎖（Update Lock）
更新鎖是為了防止死鎖而設(shè)立的。當(dāng)SQL Server 準(zhǔn)備更新數(shù)據(jù)時，它首先對數(shù)據(jù)對象作更新鎖鎖定，這樣數(shù)據(jù)將不能被修改，但可以讀取。等到SQL Server 確定要進(jìn)行更新數(shù)據(jù)操作時，它會自動將更新鎖換為獨占鎖。但當(dāng)對象上有其它鎖存在時，無法對其作更新鎖鎖定。

?

2）從程序員的角度看
鎖分為以下兩種類型：

1.樂觀鎖（Optimistic Lock）

樂觀鎖對數(shù)據(jù)庫系統(tǒng)的自動管理不感冒，需要程序員直接管理數(shù)據(jù)或?qū)ο笊系募渔i處理，并負(fù)責(zé)獲取、共享和放棄正在使用的數(shù)據(jù)上的任何鎖。

?

2.悲觀鎖（Pessimistic Lock）
悲觀鎖假定在處理數(shù)據(jù)時，不需要在應(yīng)用程序的代碼中做任何事情就可以直接在記錄上加鎖、即完全依靠數(shù)據(jù)庫來管理鎖的工作。一般情況下，當(dāng)執(zhí)行事務(wù)處理時SQL Server會自動對事務(wù)處理范圍內(nèi)更新到的表做鎖定。

?

?

鎖定優(yōu)化程序提示及其描述
優(yōu)化程序提示 優(yōu)化程序提示描述
holdlock 保持鎖定直到事務(wù)結(jié)束
nolock 檢索數(shù)據(jù)時不使用鎖
paglock 使用頁面鎖
tablock 使用表鎖
tablockx 使用獨占表鎖
updlock 使用更新鎖

如： SELECT *??? FROM authors (paglock holdlock index=aunmind)??

?

?

死鎖及其防止：

死鎖（Deadlocking） 是在多用戶或多進(jìn)程狀況下，為使用同一資源而產(chǎn)生的無法解決的爭用狀態(tài)，通俗地講，就是兩個用戶各占用一個資源，兩人都想使用對方的資源，但同時又不愿放棄自己的資源，就一直等待對方放棄資源，如果不進(jìn)行外部干涉，就將一直耗下去。

死鎖會造成資源的大量浪費，甚至?xí)瓜到y(tǒng)崩潰。在SQL Server 中解決死鎖的原則是“犧牲一個比兩個都死強(qiáng)”，即挑出一個進(jìn)程作為犧牲者，將其事務(wù)回滾，并向執(zhí)行此進(jìn)程的程序發(fā)送編號為1205 的錯誤信息。而防止死鎖的途徑就是不能讓滿足死鎖條件的情況發(fā)生，為此，用戶需要遵循以下原則：

盡量避免并發(fā)地執(zhí)行涉及到修改數(shù)據(jù)的語句；
要求每個事務(wù)一次就將所有要使用的數(shù)據(jù)全部加鎖，否則就不予執(zhí)行；
預(yù)先規(guī)定一個封鎖順序所有的事務(wù)，都必須按這個順序?qū)?shù)據(jù)執(zhí)行封鎖，例如，不同的過程在事務(wù)內(nèi)部對對象的更新執(zhí)行順序應(yīng)盡量保持一致；
每個事務(wù)的執(zhí)行時間不可太長，對程序段長的事務(wù)可考慮將其分割為幾個事務(wù)。

七，注意點

?

一般處理并發(fā)問題時的步驟：

1、開啟事務(wù)。

2、申請寫權(quán)限，也就是給對象(表或記錄)加鎖。

3、假如失敗，則結(jié)束事務(wù)，過一會重試。

4、假如成功，也就是給對象加鎖成功，防止其他用戶再用同樣的方式打開。

5、進(jìn)行編輯操作。

6、寫入所進(jìn)行的編輯結(jié)果。

7、假如寫入成功，則提交事務(wù),完成操作。

8、假如寫入失敗，則回滾事務(wù)，取消提交。

9、(7.8)兩步操作已釋放了鎖定的對象，恢復(fù)到操作前的狀態(tài)。

?

對多表的操作最好一起取得鎖,或則保證處理順序;個人感覺還是前者好,雖然效率低一些

八，附
查看鎖
ORACLE：
select object_name,session_id,os_user_name,oracle_username,process,locked_mode,status
from v$locked_object l, all_objects a
where l.object_id=a.object_id;

MS_SQL：EXEC SP_LOCK

?

數(shù)據(jù)庫事務(wù)隔離級別與鎖