簡介
ACID，是指在可靠數據庫管理系統（DBMS）中，事務(transaction)所應該具有的四個特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）.這是可靠數據庫所應具備的幾個特性.下面針對這幾個特性進行逐個講解.
理解原子性(Atomicity)
原子性意味着數據庫中的事務執行是作爲原子。即不可再分，整個語句要麼執行，要麼不執行。
在SQL SERVER中，每一個單獨的語句都可以看作是默認包含在一個事務之中:
所以，每一個語句本身具有原子性，要麼全部執行，這麼全部不執行，不會有中間狀態:
上面說了，每一條T-SQL語句都可以看作是默認被包裹在一個事務之中的,SQL
Server對於每一條單獨的語句都實現了原子性，但這種原子粒度是非常小的，如果用戶想要自己定義原子的大小，則需要包含在事務中來構成用戶自定義的原子粒度:
對於用戶來說，要用事務實現的自定義原子性往往是和業務相關的，比如銀行轉賬，從A賬戶減去100，在B賬戶增加100，如果這兩個語句不能保證原子性的話，比如從A賬戶減去100後，服務器斷電，而在B賬戶中卻沒有增加100.雖然這種情況會讓銀行很開心，但作爲開發人員的你可不希望這種結果.而默認事務中，即使出錯了也不會整個事務進行回滾。而是失敗的語句拋出異常，而正確的語句成功執行。這樣會破壞原子性。所以SQL SERVER給予了一些選項來保證事務的原子性.
SQL SERVER提供了兩大類方式來保證自定義事務的原子性：
1.通過SET XACT_ABORT ON來設置事務必須符合原子性
利用設置XACT_ABORT選項設置爲ON,來設置所有事務都作爲一個原子處理.下面例子利用兩個語句插入到數據庫，可以看到開啓SET XACT_ABORT ON選項後，事務具有了原子性:
2.按照用戶設置進行回滾(ROLLBACK)
這種方式具有更高的靈活性，開發人員可以自定義在什麼情況進行ROLLBACK,利用TRY CATCH語句和@@ERROR進行判斷都屬於這種方式.
理解一致性(Consistency)
一致性,即在事務開始之前和事務結束以後，數據庫的完整性約束沒有被破壞。
一致性分爲兩個層面
1.數據庫機制層面
數據庫層面的一致性是，在一個事務執行之前和之後，數據會符合你設置的約束（唯一約束，外鍵約束,Check約束等)和觸發器設置.這一點是由SQL SERVER進行保證的.
2.業務層面
對於業務層面來說,一致性是保持業務的一致性.這個業務一致性需要由開發人員進行保證.很多業務方面的一致性可以通過轉移到數據庫機制層面進行保證.比如，產品只有兩個型號，則可以轉移到使用CHECK約束使某一列必須只能存這兩個型號.
比如你定義一個事務，裏面的操作是A,B，C三步，系統原子性能保證的是這三步要麼都執行，要麼都不執行，不可拆分。但是有可能你這三部破壞了數據的一致性，比如你定義了從A賬戶劃撥200塊給B賬戶。如果你的事務裏只包含從A賬戶扣款，而不包含B賬戶加錢。那麼系統保證原子性後，能保證要麼從A賬戶都扣款成功，要麼都不成功，不會出現扣了一半款之類的異常情況。但是沒辦法保證B賬戶加錢了。所以A賬戶扣款，B賬號加錢，這是一個連續的動作，業務邏輯上要保證一致性，所以必須把兩個步驟放在一個事務裏，這樣才能保證一致性。
理解隔離性（Isolation)
隔離性：指的是在併發環境中，發事務之間互相影響的程度（即併發事務間數據的可見程度），當不同的事務同時操縱相同的數據時，每個事務都有各自的完整數據空間。由併發事務所做的修改必須與任何其他併發事務所做的修改隔離。事務查看數據更新時，數據所處的狀態要麼是另一事務修改它之前的狀態，要麼是另一事務修改它之後的狀態，事務不會查看到中間狀態的數據。
在Windows中，如果多個進程對同一個文件進行修改是不允許的，Windows通過這種方式來保證不同進程的隔離性:
而SQL
Server中，通過SQL SERVER對數據庫文件進行管理，從而可以讓多個進程可以同時訪問數據庫:
事務間的相互影響
SQL Server利用加鎖和阻塞來保證事務之間不同等級的隔離性.
一般情況下，完全的隔離性是不現實的，完全的隔離性要求數據庫同一時間只執行一條事務（即事務的執行時序列化的），這樣的性能可想而知.想要理解SQL Server中對於隔離性的保障，首先要了解事務之間是如何幹擾的.但是同一個事務內的數據庫操作的數據是透明的，即同一個事務內的一個數據庫操作可以讀取另一個未提交（commit）的數據庫操作。
事務之間的互相影響的情況分爲幾種，分別爲:髒讀(Dirty Read)，不可重複讀（Non-Repeatable Reads），幻讀（Phantom Reads）
髒讀
髒讀意味着一個事務讀取了另一個事務未提交的數據,而這個數據是有可能回滾的:
下面來看一個例子:
兩個事務，事務A插入一條數據，但未提交，事務B在此期間進行了讀取，讀取到了事務A未提交的數據，造成髒讀
不可重複讀(Unrepeatable Read)
不可重複讀意味着，在數據庫訪問中，一個事務先後讀取同一條記錄，但兩次讀取的數據不同，我們稱之爲不可重複讀。也就是說，這個事務在兩次讀取之間該數據被其它事務所修改。就是說事務A中兩處讀取數據，第一次讀時是100，然後事務B把值改成了200，事務A再讀一次，結果就發現值變了，造成A事務數據混亂。
幻讀(phantom read)
幻讀，和不可重複讀相似，也是同一個事務中多次讀不一致的問題。但是不可重複讀的不一致是因爲它所要取的數據集被改變了，而幻讀所要讀的數據不一致卻不是他所要讀的數據改變，而是它的條件數據集改變。比如：Select id where name="ppgogo*"，第一次讀去了6個符合條件的id，第二次讀時，由於事務B把第一個貼的名字由"dd"改成了“ppgogo9”，結果取出來7個數據，就好象發生了幻覺一樣.
事務間相互影響解決方案--設置隔離級別
爲了避免上述幾種事務之間的影響,通過設置不同的隔離等級來進行不同程度的避免。因爲高的隔離等級意味着更多的鎖，從而犧牲性能.所以這個選項開放給了用戶根據具體的需求進行設置。不過默認的隔離等級Read Commited符合了99%的實際需求.事務隔離級別的出現，是爲了使你在性能與數據的有效性之間做一個平衡，不是說級別越高越好，只有合適纔是最好的。
隔離事務之間的影響是通過鎖來實現的，這個概念比較繁雜，所以本文不會詳細對這個概念進行講解.通過阻塞來阻止上述效果
SQL Server提供了5種選項來避免不同級別的事務之間的影響
隔離等級由低到高分別爲
1）未提交讀（Read Uncommitted）(最高的性能，但可能出現髒讀，不可重複讀，幻讀): SELECT語句以非鎖定方式被執行.
2）提交讀（Read Committed）(可能出現不可重複讀，幻讀)：只能讀取到已經提交的數據。
3）可重複讀（Repeated Read）(可能出現幻讀):通過加共享記錄鎖實現，即 SELECT .... FOR UPDATE
4）串行讀（Serializable）(最低的性能，Range鎖會導致併發下降)：完全的串行化讀，所有SELECT語句都被隱式的轉換成SELECT ... LOCK IN SHARE MODE，即讀取使用表級共享鎖，讀寫相互都會阻塞。隔離級別最高。
5） SNOPSHOT(這個是通過在tempDB中創建一個額外的副本來避免髒讀，不可重複讀，會給tempDB造成額外負擔，因爲不是標準ANSI SQL標準，不詳細討論)
隔離級別對比表：
總之，不同的隔離級別是通過加不同的鎖，造成阻塞來實現的，來看一個例子:
SQL SERVER通過阻塞來阻止髒讀，所以保持獨立性會以付出性能作爲代價：
理解持久性（Durability)
持久性，意味着在事務完成以後，該事務所對數據庫所作的更改便持久的保存在數據庫之中，並不會被回滾。
即使出現了任何事故比如斷電等，事務一旦提交，則持久化保存在數據庫中.
SQL SERVER通過write-ahead transaction log來保證持久性。write-ahead transaction log的意思是，事務中對數據庫的改變在寫入到數據庫之前，首先寫入到事務日誌中。而事務日誌是按照順序排號的（LSN）。當數據庫崩潰或者服務器斷點時，重啓動SQL SERVER，SQL SERVER首先會檢查日誌順序號，將本應對數據庫做更改而未做的部分持久化到數據庫，從而保證了持久性.
總結：
參看博文：http://www.cnblogs.com/CareySon/archive/2012/01/29/2331088.html