我跟事務可能結了很久的仇，總是因為它被同事們各種笑話，我也甚是慚愧hahahahaha~，今兒閒了來整理一下

一、事務模型

1. 自動事務：在事務中，事務自動提交，發生錯誤時自動回滾。系統自動預設

2.隱式事務：每一條資料操作語句都自動地成為一個事務，事務的開始是隱式的，事務的結束有明確的標記。需要commit、rollback語句提交或回滾當前事務

3. 顯式事務：每個事務都有顯式的開始和結束標記。當使用starttransaction、commit時發生顯示事務

二、事務特性

       資料庫事務的特性ACID，不用說也是必知的，看好了是這幾隻Atomicity、Consistency、Isolation、Durability，一般有疑問或者容易出問題的一般在隔離性上

1、原子性（Atomicity)：事務的操作要麼全執行要麼全不執行；

2、一致性(Consistency)：事務前後，資料庫的狀態都必須處於一致狀態；

3、隔離性（Isolation）：一個事務的執行過程不受其它事務的干擾；

4、永續性（Durability）：事務一旦提交，對資料庫做出的更新是永久的；

三、併發控制

       資料庫中的資料一般是多個使用者共享的資源，而多個使用者對資料庫同時操作就產生了併發行為，對併發行為的控制有兩種方式：

序列控制：一個事務完成之後，再開始另一個事務，按順序執行。

並行控制：多個事務同時執行。

       事務是併發控制的基本單位，保證事務ACID的特性是事務處理的首要任務，而併發操作有可能會破壞其ACID特性。由併發引起的資料不一致有以下幾種情況：

1. 丟失更新：兩個事務同時更新一行資料，一個事務對資料的更新把另一個事務對資料的更新覆蓋了。

2. 髒讀：在一個事務處理過程裡讀取了另一個未提交的事務中的資料。

3.不可重複讀：在一個事務內多次讀取某個資料，讀取結果卻不同。這是由於在查詢間隔，被另一個事務修改並提交了。

4.幻讀：一個事務內讀取到了別的事務插入或刪除的資料，導致前後讀取不一致。幻讀解決了不可重複讀，保證在同一個事務裡，查詢的結果都是事務開始時的狀態（一致性），但是如果在該事務期間另一個事務同時提交了新資料，那麼在本事務更新時，就會發現這些新資料，以至之前讀到的資料是虛幻的。

區別：

       不可重複讀和幻讀都是讀取了另一條已經提交的事務。不可重複讀查詢的都是同一個資料項，而幻讀針對的是一批資料整體（比如資料的個數）。

       不可重複讀是由於另一個事務對資料的更改所造成的，而幻讀是由於另一個事務插入或刪除引起的

四、隔離級別

       事務的隔離機制是為了防止事務之間的相互影響，保證資料的一致性。事務的隔離級別有四級，預設隔離級別是“可重複讀”（REPEATABLE READ）。

1. 未提交讀（ReadUncommitted）：允許髒讀，但不允許更新丟失。如果一個事務在寫資料，則不允許另一個事務同時進行寫操作，但允許其他事務讀此行資料。該隔離級別可以通過“排他寫鎖”實現。

2.提交讀（ReadCommitted）：允許不可重複讀取，但不允許髒讀。讀取資料的事務允許其他事務繼續訪問該行資料，但是未提交的寫事務將會禁止其他事務訪問該行。該隔離級別可以通過“瞬間共享讀鎖”和“排他寫鎖”實現。

3.可重複讀（RepeatableRead）：禁止不可重複讀取和髒讀，但是會出現幻讀。讀取資料的事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。該隔離級別可以通過“共享讀鎖”和“排他寫鎖”實現

4.序列化（Serializable）：提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接著一個地執行，不能併發執行。僅僅通過“行級鎖”是無法實現事務序列化的，必須通過其他機制保證新插入的資料不會被剛執行查詢操作的事務訪問到。

       四個級別的隔離性逐漸增強，隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大。一般情況下優先將資料庫系統的隔離級別設為RC，它可以避免髒讀，並且有較好的併發效能，但是會導致不可重複讀、幻讀，在出現這些問題時，可由程式採用悲觀鎖、樂觀鎖來控制。

PS：

       整理了好久好久都要整完了，一個手誤把東西都刪除了，心哇涼哇涼的，又從新來了一遍，反正不開心了，不再繼續整理鎖，想哭的心都有好幾丈高了

        ～～～～～～

       很久沒來這裡，甚是想念

這段時間沒有結婚，沒有生娃，也沒有去浪跡天涯，，，嗯～我只是陷入加班不能自拔了。。。