事務是指對系統進行的一組操作，為了保證系統的完整性，事務需要具有ACID特性，具體如下： 1. 原子性（Atomic）      一個事務包含多個操作，這些操作要麼全部執行，要麼全都不執行。實現事務的原子性，要支援回滾操作，在某個操作失敗後，回滾到事務執行之前的狀態。      回滾實際上是一個比較高層抽象的概念，大多數DB在實現事務時，是在事務操作的資料快照上進行的（比如，MVCC），並不修改實際的資料，如果有錯並不會提交，所以很自然的支援回滾。

     而在其他支援簡單事務的系統中，不會在快照上更新，而直接操作實際資料。可以先預演一邊所有要執行的操作，如果失敗則這些操作不會被執行，通過這種方式很簡單的實現了原子性。

舉個例子：

A想要從自己的帳戶中轉1000塊錢到B的帳戶裡。那個從A開始轉帳，到轉帳結束的這一個過程，稱之為一個事務。在這個事務裡，要做如下操作：

1. 從A的帳戶中減去1000塊錢。如果A的帳戶原來有3000塊錢，現在就變成2000塊錢了。

2. 在B的帳戶里加1000塊錢。如果B的帳戶如果原來有2000塊錢，現在則變成3000塊錢了。

如果在A的帳戶已經減去了1000塊錢的時候，忽然發生了意外，比如停電什麼的，導致轉帳事務意外終止了，而此時B的帳戶裡還沒有增加1000塊錢。那麼，我們稱這個操作失敗了，要進行回滾。回滾就是回到事務開始之前的狀態，也就是回到A的帳戶還沒減1000塊的狀態，B的帳戶的原來的狀態。此時A的帳戶仍然有3000塊，B的帳戶仍然有2000塊。

我們把這種要麼一起成功（A帳戶成功減少1000，同時B帳戶成功增加1000），要麼一起失敗（A帳戶回到原來狀態，B帳戶也回到原來狀態）的操作叫原子性操作。

如果把一個事務可看作是一個程式,它要麼完整的被執行,要麼完全不執行。這種特性就叫原子性

2. 一致性（Consistency）      一致性是指事務使得系統從一個一致的狀態轉換到另一個一致狀態。事務的一致性決定了一個系統設計和實現的複雜度。事務可以不同程度的一致性：      強一致性：讀操作可以立即讀到提交的更新操作。      弱一致性：提交的更新操作，不一定立即會被讀操作讀到，此種情況會存在一個不一致視窗，指的是讀操作可以讀到最新值的一段時間。      最終一致性：是弱一致性的特例。事務更新一份資料，最終一致性保證在沒有其他事務更新同樣的值的話，最終所有的事務都會讀到之前事務更新的最新值。如果沒有錯誤發生，不一致視窗的大小依賴於：通訊延遲，系統負載等。      其他一致性變體還有：      單調一致性：如果一個程序已經讀到一個值，那麼後續不會讀到更早的值。

     會話一致性：保證客戶端和伺服器互動的會話過程中，讀操作可以讀到更新操作後的最新值。

3. 隔離性（Isolation）      併發事務之間互相影響的程度，比如一個事務會不會讀取到另一個未提交的事務修改的資料。在事務併發操作時，可能出現的問題有：      髒讀：事務A修改了一個數據，但未提交，事務B讀到了事務A未提交的更新結果，如果事務A提交失敗，事務B讀到的就是髒資料。      不可重複讀：在同一個事務中，對於同一份資料讀取到的結果不一致。比如，事務B在事務A提交前讀到的結果，和提交後讀到的結果可能不同。不可重複讀出現的原因就是事務併發修改記錄，要避免這種情況，最簡單的方法就是對要修改的記錄加鎖，這回導致鎖競爭加劇，影響效能。另一種方法是通過MVCC可以在無鎖的情況下，避免不可重複讀。      幻讀：在同一個事務中，同一個查詢多次返回的結果不一致。事務A新增了一條記錄，事務B在事務A提交前後各執行了一次查詢操作，發現後一次比前一次多了一條記錄。幻讀是由於併發事務增加記錄導致的，這個不能像不可重複讀通過記錄加鎖解決，因為對於新增的記錄根本無法加鎖。需要將事務序列化，才能避免幻讀。      事務的隔離級別從低到高有：      Read Uncommitted：最低的隔離級別，什麼都不需要做，一個事務可以讀到另一個事務未提交的結果。所有的併發事務問題都會發生。      Read Committed：只有在事務提交後，其更新結果才會被其他事務看見。可以解決髒讀問題。      Repeated Read：在一個事務中，對於同一份資料的讀取結果總是相同的，無論是否有其他事務對這份資料進行操作，以及這個事務是否提交。可以解決髒讀、不可重複讀。      Serialization：事務序列化執行，隔離級別最高，犧牲了系統的併發性。可以解決併發事務的所有問題。

     通常，在工程實踐中，為了效能的考慮會對隔離性進行折中。

4. 永續性（Durability）      事務提交後，對系統的影響是永久的。