為了保證併發時資料的完整性以及正確性, 資料庫中引入了事務的概念 , 意為在某一個功能單元 , 要麼同時成功 , 要麼同時失敗 .

1.事務

    1.1  資料庫事務有四大特性:

       1.1.1原子性(Atomicity)：事務是資料庫的邏輯工作單位，它對資料庫的修改要麼全部執行，要麼全部不執行。
       1.1.2 一致性(Consistemcy)：事務執行前後，資料庫的狀態都滿足所有的完整性約束。
       1.1.3 隔離性(Isolation)：併發執行的事務是隔離的，保證多個事務互不影響。如果有兩個事務，執行在相同的時間內，執行相同的功能，事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為序列化，為了防止事務操作間的混淆，必須序列化或序列化請求，使得在同一時間僅有一個請求用於同一資料。通過設定資料庫的隔離級別，可以達到不同的隔離效果。

       1.1.4 永續性(Durability)：一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的。

 1.2 資料庫事務有四大隔離級別:

有四級，預設是“可重複讀”（REPEATABLE READ） ; oracel 預設級別是  讀已提交;

·        未提交讀（READUNCOMMITTED）。另一個事務修改了資料，但尚未提交，而本事務中的SELECT會讀到這些未被提交的資料（髒讀）。

·        提交讀（READCOMMITTED）。本事務讀取到的是最新的資料（其他事務提交後的）。問題是，在同一個事務裡，前後兩次相同的SELECT會讀到不同的結果（不重複讀）。

·        

·        序列化（SERIALIZABLE）。讀操作會隱式獲取共享鎖，可以保證不同事務間的互斥。

四個級別逐漸增強，每個級別解決一個問題。

        可能產生的問題

.         髒讀，最容易理解。另一個事務修改了資料，但尚未提交，而本事務中的SELECT會讀到這些未被提交的資料。

·        不重複讀。解決了髒讀後，會遇到，同一個事務執行過程中，另外一個事務提交了新資料，因此本事務先後兩次讀到的資料結果會不一致。

·        幻讀。解決了不重複讀，保證了同一個事務裡，查詢的結果都是事務開始時的狀態（一致性）。但是，如果另一個事務同時提交了新資料，本事務再更新時，就會“驚奇的”發現了這些新資料，貌似之前讀到的資料是“鬼影”一樣的幻覺。

1.3 事務執行的三種模式
    1.3.1 自動提交事務：預設事務管理模式。如果一個語句成功地完成，則提交該語句；如果遇到錯誤，則回滾該語句。
    1.3.2 顯式事務：以BEGIN TRANSACTION顯式開始，以COMMIT或ROLLBACK顯式結束。

    1.3.3 隱性事務：當連線以此模式進行操作時，sql將在提交或回滾當前事務後自動啟動新事務。無須描述事務的開始，只需提交或回滾每個事務。它生成連續的事務鏈。

1.4 資料庫事務與事務日誌

        以mysql的innodb的事務為例，通過事務日誌實現ACID特性。事務日誌遵循WAL（Write-Ahead Logging 預寫日誌方式）協議。

        以oracel為例: 檢視資料庫日誌檔案路徑可用   SELECT * FROM V$logfile;  檢視近期操作日誌可用SELECT * FROM V$sql;    不過查出來的日誌直接看看得不是很直觀 ,  可用oracel提供的LogMiner來檢視分析後的日誌.

         資料庫日誌檔案是非常重要的檔案 , 如果不小心對資料庫進行誤刪等操作 ,  恢復時日誌檔案是很好的依據.

2. 鎖

    資料庫事務底層的實現就是通過鎖機制來實現的, 從大的分類上, 我們可以將鎖分為樂觀鎖和悲觀鎖, 而悲觀鎖又可延伸出共享鎖(讀鎖)  排他鎖(寫鎖)  再細分一點  可以分為行鎖 表鎖 頁鎖

樂觀鎖不是資料庫自帶的，需要我們自己去實現。樂觀鎖是指操作資料庫時(更新操作)，想法很樂觀，認為這次的操作不會導致衝突，在操作資料時，並不進行任何其他的特殊處理（也就是不加鎖），而在進行更新後，再去判斷是否有衝突了。

通常實現是這樣的：在表中的資料進行操作時(更新)，先給資料表加一個版本(version)欄位，每操作一次，將那條記錄的版本號加1。也就是先查詢出那條記錄，獲取出version欄位,如果要對那條記錄進行操作(更新),則先判斷此刻version的值是否與剛剛查詢出來時的version的值相等，如果相等，則說明這段期間，沒有其他程式對其進行操作，則可以執行更新，將version欄位的值加1；如果更新時發現此刻的version值與剛剛獲取出來的version的值不相等，則說明這段期間已經有其他程式對其進行操作了，則不進行更新操作。

共享鎖【S鎖】
又稱讀鎖，若事務T對資料物件A加上S鎖，則事務T可以讀A但不能修改A，其他事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。這保證了其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改。

排他鎖【X鎖】
又稱寫鎖。若事務T對資料物件A加上X鎖，事務T可以讀A也可以修改A，其他事務不能再對A加任何鎖，直到T釋放A上的鎖。這保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。

行鎖，由字面意思理解，就是給某一行加上鎖，也就是一條記錄加上鎖。

比如SELECT * from city where id = "1"  lock in share mode; 

由於對於city表中,id欄位為主鍵，就也相當於索引。執行加鎖時，會將id這個索引為1的記錄加上鎖，那麼這個鎖就是行鎖。

表鎖，和行鎖相對應，給這個表加上鎖。

mysql innodb事務死鎖：

   事務A需要先查詢資料1，然後修改資料2；

   事務B需要先查詢資料2，然後修改資料1；

此時2個事務併發執行，由於mysql innodb的預設隔離級別是可重複讀，讀鎖、寫鎖只能在事務結束才會釋放。

事務A中需要等待事務B釋放資料2的共享鎖，才能執行對資料2新增排他鎖；事務B需要等待事務A釋放資料1的共享鎖，才能執行對資料1新增排他鎖。這樣會就出現事務死鎖

這種死鎖在oracle中就不會出現，因為oracle的預設隔離級別是讀已提交，共享鎖在執行完查詢之後就會釋放，不會導致排他鎖無法新增的問題。

有四級，預設是“可重複讀”（REPEATABLE READ）。

·        未提交讀（READUNCOMMITTED）。另一個事務修改了資料，但尚未提交，而本事務中的SELECT會讀到這些未被提交的資料（髒讀）。

·        提交讀（READCOMMITTED）。本事務讀取到的是最新的資料（其他事務提交後的）。問題是，在同一個事務裡，前後兩次相同的SELECT會讀到不同的結果（不重複讀）。

·        可重複讀（REPEATABLEREAD）。在同一個事務裡，SELECT的結果是事務開始時時間點的狀態，因此，同樣的SELECT操作讀到的結果會是一致的。但是，會有幻讀現象（稍後解釋）。

·        序列化（SERIALIZABLE）。讀操作會隱式獲取共享鎖，可以保證不同事務間的互斥。

四個級別逐漸增強，每個級別解決一個問題。