事務具基本特徵（ACID）
① Atomi(原子性)：事務中包含的操作被看做一個整，要麼完全部成功，要麼全部失敗。
② Consistency(一致性)：事務在完成時，必須是所有的資料都保持一致狀態，保證了資料的完整性和一致性。
③ Isolation(隔離性)：當多個使用者併發訪問資料庫時，比如操作同一張表時，資料庫為每一個使用者開啟的事務，不能被其他事務的操作所干擾，多個併發事務之間要相互隔離。
這裡的隔離性就是下面我們要說的隔離級別，為了減少事務在修改資料上的相互影響。
④ Durability(永續性)：一個事務一旦被提交了，那麼對資料庫中的資料的改變就是永久性的，即便資料庫系統遇到故障也不會丟失提交事務的操作。
事務的傳播行為
事務傳播行為（propagation behavior）指的就是當一個事務方法A被另一個事務方法B呼叫時，這個事務方法A應該如何進行。換句話說，需要發生方法件的呼叫，才會存在傳播行為，對於單個事務方法而已，沒有傳播的概念。
| 傳播行為 | 含義 | 應用場景 |
|---|---|---|
| REQUIRED | 預設傳播行為，當前上下文不存在事務，所以會開啟一個新的事務，當上下文存在事務，則融入當前事務（它是個機會主義者，既可以暗度陳倉，也可以獨當一面） | 大部分簡單場景 |
| SUPPORTS | 如果存在一個事務，支援當前事務。如果沒有事務，則非事務的執行（它是個保守派，隨波逐流，從不另起爐灶） | 查詢 |
| MANDATORY | 如果存在一個事務，支援當前事務。如果沒有一個活動的事務，則丟擲異常（它是個獨裁者，只許州官放火，不許百姓點燈） | |
| REQUIRES_NEW | 它會開啟一個新的事務。如果一個事務已經存在，則先將這個存在的事務掛起。（它是個革新派，開天闢地） | 批量操作時，需要對單調資料進行控制 |
| NOT_SUPPORTED | 總是非事務地執行，並掛起任何存在的事務（他是個悲觀主義者，不主動，誰來都拒絕） | |
| NEVER | 總是非事務地執行，如果存在一個活動事務，則丟擲異常（怎麼說，這個有點反人類） | |
| NESTED | 巢狀事務一個非常重要的概念就是內層事務依賴於外層事務。外層事務失敗時，會回滾內層事務所做的動作。而內層事務操作失敗並不會引起外層事務的回滾。（害，活像一個愛情弱勢方，受害者，左右不了對方，被對方左右） |
事務的隔離級別
準確來說，事務的隔離級別只有四個，分別為：
- 讀未提交（READ_UNCOMMITTED）
- 讀已提交（READ_COMMITTED）
- 可重複讀（REPEATABLE_READ）
- 序列化（SERIALIZABLE）
單單看這幾個字有點幹，其他的先不管，先來看一下他們都能解決啥問題，以及無法解決什麼問題先
| 異常現象 | 髒讀 | 不可重複讀 | 幻讀 |
|---|---|---|---|
| 未提交讀 | √ | √ | √ |
| 讀寫提交 | × | √ | √ |
| 可重複讀 | × | × | √ |
| 序列化 | × | × | × |
如何理解上面這個表格呢？首先，如果是簡單的查詢，那是不存在的什麼問題的，因為你只進行了查詢而已。那麼如果你有對資料庫的更新修改操作，是不是就會產生問題呢？不一定，如果這個時間內只有一個事務，那你做再多的操作，都是不會有問題的，要麼這個事務的操作全部成功，要麼全部失敗。所以在對事務產生問題的討論上，都是針對併發事務。這一點與事務的傳播性的特點一樣。簡單的理解，就是同一時間，對同一資料有多個事務在操作。
那我們都知道，每一個事務的裡的操作，都會被計算機分割成很多的原子操作，由cpu進行排程執行，所以就涉及這些操作的一個排列問題，但我們知道cpu的排程是隨機的，所以的就會產生很多可能性。這些操作的執行順序，導致了面臨一些問題。
最低階別讀未提交（READ_UNCOMMITTED），什麼問題都有可能發生，不適合併發事務場景
由上面所提到的事務的永續性可以得知，事務的持久化，是建立在事務被提交的基礎上的。也就是說，事務A沒提交，對資料的操作都不算真正的生效，那麼如果在未提交前，被別的事務B的讀取到這部分資料，那麼你最終提交的化還好，嚴格來說不算髒資料，但假如事務A回滾了，那讀的這部分資料其實是錯誤的，我們把它稱之為“髒資料”，這是併發事務面臨的第一個問題。
要解決“髒資料”問題，就必須保證一個事務不會讀到另一個並行事務已修改但未提交的資料，這正是讀已提交（READ_COMMITTED）隔離級別所要求的。換句話說就是“我修改的資料還沒提交你不能讀”。解決了髒資料問題後。我讀到的資料的確都是“生效”的了。
但這會帶來一個問題，單事務A需要對一個資料多次讀取的時候，中間可能存在一個可能：事務B修改這個資料了，由該級別讀到的資料是已提交可知，事務B對資料的修改操作肯定是生效的了，所以事務A多次讀到的結果可能不一致，這就是“不可重複讀”問題。
要解決“不可重複讀”問題，很顯然，我就得加強約束，上一級是我修改的資料還沒提交你不能讀，這次是當我讀資料開始，到我所在的事務還沒提交之前，你不能讀，這意味著不管事務A讀資料後有多少操作，併發事務B都得等待，可以看到的“鎖住”的範圍更大了，也相應帶來更大的損耗。此時解決重複讀的問題，級別是可重複讀（REPEATABLE_READ）
但可重複讀級別解決的是同一競爭資料的重複讀問題，假如事務A多次通過特定條件多次讀取m條資料，有事務C，插入n條資料服務事務A查詢條件，或者修改了其他t條資料同樣符合事務A的條件，那事務A後面讀取可能就是m+n或m+t條資料了，此為”幻讀“現象，要解決此問題
要解決幻讀現象，只能祭出最後殺招，序列化（SERIALIZABLE）級別
總結如下
| 隔離等級 | 含義 |
|---|---|
| READ_UNCOMMITTED | 最低等級，從上表可以看到，啥問題解決不了，所以當併發事務操作同一資料時，啥情況都可能發生，所以一般不用於併發事務場景 |
| READ_COMMITTED | 保證了一個事務不會讀到另一個並行事務已修改但未提交的資料 |
| REPEATABLE_READ | 保證了一個事務不會修改已經由另一個事務讀取但未提交（回滾）的資料 |
| SERIALIZABLE | 最嚴格的級別，事務序列執行，資源消耗最大 |
資料庫實現
未提交讀的資料庫鎖情況（實現原理）
事務在讀資料的時候並未對資料加鎖。
務在修改資料的時候只對資料增加行級共享鎖。
提交讀的資料庫鎖情況
事務對當前被讀取的資料加 行級共享鎖（當讀到時才加鎖），一旦讀完該行，立即釋放該行級共享鎖；
事務在更新某資料的瞬間（就是發生更新的瞬間），必須先對其加 行級排他鎖，直到事務結束才釋放。
可重複讀的資料庫鎖情況
事務在讀取某資料的瞬間（就是開始讀取的瞬間），必須先對其加 行級共享鎖，直到事務結束才釋放；
事務在更新某資料的瞬間（就是發生更新的瞬間），必須先對其加 行級排他鎖，直到事務結束才釋放。
可序列化的資料庫鎖情況
事務在讀取資料時，必須先對其加 表級共享鎖 ，直到事務結束才釋放；
事務在更新資料時，必須先對其加 表級排他鎖 ，直到事務結束才釋放。