MySQL 系列（三）事務

MySQL 系列（三）事務

一組要麼同時執行成功，要麼同時執行失敗的 SQL 語句。是數據庫操做的一個執行單元!

事務開始於：

1. 鏈接到數據庫上，並執行條 DML 語句(INSERT、 UPDATE 或 DELETE)。
2. 前一個事務結束後，又輸入了另一條 DML 語句。

若是 JDBC 鏈接是在自動提交模式下，它在默認狀況下，那麼每一個 SQL 語句都是在其完成時提交到數據庫。

事務結束於：

1. 執行 COMMIT 或 ROLLBACK 語句
2. 執行條 DDL 語句，例如 CREATE TABLET 語句；在這種狀況下，會自動執行 COMMIT 語句
3. 執行 DCL 語句，例如 GRANT 語句；在這種狀況下，會自動執行 COMMIT 語句
4. 斷開與數據庫的鏈接
5. 執行了一條 DML 語句，該語句卻失敗了；在這種狀況中，會爲這個無效的 DML 語句執行 ROLLBACK 語句

下面的例子演示瞭如何使用一個提交和回滾對象：

try{
    // Assume a valid connection object conn
    conn.setAutoCommit(false);
    Statement stmt = conn.createStatement();

    String SQL = "INSERT INTO Employees "VALUES (106, 20, 'Rita', 'Tez')";
    stmt.executeUpdate(SQL); 
    // Submit a malformed SQL statement that breaks
    String SQL = "INSERTED IN Employees "VALUES (107, 22, 'Sita', 'Singh')";
    stmt.executeUpdate(SQL);
    // If there is no error.
    conn.commit();
}catch(SQLException e){
    // If there is any error.
    conn.rollback();
}

1、事務的四大特色(ACID)

1. atomicity(原子性)

   表示一個事務內的全部操做是一個總體，要麼所有成功，要麼全失敗。

2. consistency(一致性)

   表示個事務內有一個操做失敗時，全部的更改過的數據都必須回滾到修改前的狀態。

3. isolation(隔離性)

   事務查看數據時數據所處的狀態，要麼是另外一併發事務修改它以前的狀態，要麼是另外一事務修改它以後的狀態，事務不會直看中間狀態的數據。

4. durability(持久性)

   持久性事務完成以後，它對於系統的影響是永久性的。

2、事務的 4 種隔離級別

數據庫事務的隔離級別由低到高有如下 4 種：

1. 讀取未提交(Read Uncommitted)
2. 讀取已想交(Read Committed)
3. 可重複讀(Repeatable Read)
4. 序列化(serializable)

在事務的併發操做中可能會出現髒讀，不可重複讀，幻讀。下面經過事例一一闡述它們的概念與聯繫。

2.1 Read uncommitted

讀未提交，顧名思義，就是一個事務能夠讀取另外一個未提交事務的數據。

事例：老闆要給程序員發工資，程序員的工資是3.6萬/月。可是發工資時老闆不當心按錯了數字，按成3.9萬/月，該錢已經打到程序員的戶口，可是事務尚未提交，就在這時，程序員去查看本身這個月的工資，發現比往常多了3千元，覺得漲工資了很是高興。可是老闆及時發現了不對，立刻回滾差點就提交了的事務，將數字改爲3.6萬再提交。

分析：實際程序員這個月的工資仍是3.6萬，可是程序員看到的是3.9萬。他看到的是老闆還沒提交事務時的數據。 這就是髒讀。

那怎麼解決髒讀呢？Read committed！讀提交，能解決髒讀問題。

2.2 Read committed

讀提交，顧名思義，就是一個事務要等另外一個事務提交後才能讀取數據。

事例：程序員拿着信用卡去享受生活（卡里固然是隻有3.6萬），當他埋單時（程序員事務開啓），收費系統事先檢測到他的卡里有3.6萬，就在這個時候！！程序員的妻子要把錢所有轉出充當家用，並提交。當收費系統準備扣款時，再檢測卡里的金額，發現已經沒錢了（第二次檢測金額固然要等待妻子轉出金額事務提交完）。程序員就會很鬱悶，明明卡里是有錢的…

分析：這就是讀提交，如有事務對數據進行更新（UPDATE）操做時，讀操做事務要等待這個更新操做事務提交後才能讀取數據，能夠解決髒讀問題。但在這個事例中，出現了一個事務範圍內兩個相同的查詢卻返回了不一樣數據，這就是不可重複讀。

那怎麼解決可能的不可重複讀問題？Repeatable read ！

2.3 Repeatable read

重複讀，就是在開始讀取數據（事務開啓）時，再也不容許修改操做。

事例：程序員拿着信用卡去享受生活（卡里固然是隻有3.6萬），當他埋單時（事務開啓，不容許其餘事務的UPDATE修改操做），收費系統事先檢測到他的卡里有3.6萬。這個時候他的妻子不能轉出金額了。接下來收費系統就能夠扣款了。

分析：重複讀能夠解決不可重複讀問題。寫到這裏，應該明白的一點就是，不可重複讀對應的是修改，即 UPDATE 操做。可是可能還會有幻讀問題。由於幻讀問題對應的是插入 INSERT 操做，而不是 UPDATE 操做。

何時會出現幻讀？

事例：程序員某一天去消費，花了 2 千元，而後他的妻子去查看他今天的消費記錄（全表掃描 FTS，妻子事務開啓），看到確實是花了 2 千元，就在這個時候，程序員花了1萬買了一部電腦，即新增 INSERT 了一條消費記錄，並提交。當妻子打印程序員的消費記錄清單時（妻子事務提交），發現花了 1.2 萬元，彷佛出現了幻覺， 這就是幻讀。

那怎麼解決幻讀問題？Serializable！

2.4 Serializable 序列化

Serializable 是最高的事務隔離級別，在該級別下，事務串行化順序執行，能夠避免髒讀、不可重複讀與幻讀。可是這種事務隔離級別效率低下，比較耗數據庫性能，通常不使用。

值得一提的是：大多數數據庫默認的事務隔離級別是 Read committed，好比 Sql Server , Oracle。Mysql 的默認隔離級別是 Repeatable read。

參考：

《事務的隔離級別》：http://www.javashuo.com/article/p-frkpcrnk-gq.html

---

天天用心記錄一點點。內容也許不重要，但習慣很重要！