【MySQL】我這樣分析MySQL中的事務，面試官對我另眼相看！！

寫在前面

相信大部分小夥伴在面試過程當中，只會針對面試官提出的表面問題來進行回答。其實否則，面試官問的每個問題都是通過深思熟慮的，面試的時間相對來講也是短暫的，面試官不可能在很短的時間內就對你很是瞭解，他想經過幾個問題來考察你所掌握的知識的深度和廣度，若是你只是回答面試官表面問你的問題，向擠牙膏同樣，問一點，答一點，結果不用說，確定是涼涼了。

面試問題

說說什麼是事務？併發事務會帶來哪些問題呢？

分析問題

表面上看，面試官是問了兩個問題。一個是：什麼是事務，也就是讓你說說事務的基本概念；另外一個是：併發事務會帶來哪些問題。

實則否則，聽到面試官這樣問，你不要隨意回答。要用極短的時間思考一下，面試官究竟想要獲得什麼答案。

對於第一個問題：說說什麼是事務？就只是讓你簡單的說說事務的基本概念嗎？基本概念相信是個學過數據庫的小學生都會，面試官爲何會問你這個問題呢？此時，你須要揣測面試官的心理。此時的面試官其實想問你的不久是事務的基本概念，並且他也想讓你說出事務的特性，也就是四大屬性。這纔是這個問題的核心所在！

對於第二個問題：併發事務會帶來哪些問題呢？就只是想問一下會帶來哪些問題嗎？知道問題，不知道如何解決問題，這樣的面試者面試官能要嗎？究其本質，面試官是想問你併發事務會帶來哪些問題，有哪些解決方案可以解決這些問題！這纔是面試官想要的答案！

綜上，面試官本質上問的問題是：什麼是事務？事務的四大特性是什麼？併發事務會帶來哪些問題？有哪些解決方案？你只有深入理解了面試官提問的本質，才能更好的回答面試官所提出的問題。否則，你應付面試官，面試官也會應付你。

什麼是事務？

事務的概念理解起來還比較簡單的：事務是指做爲單個邏輯工做單元執行的一系列操做，要麼徹底地執行，要麼徹底地不執行。 事務處理能夠確保除非事務性單元內的全部操做都成功完成，不然不會永久更新面向數據的資源。經過將一組相關操做組合爲一個要麼所有成功要麼所有失敗的單元，能夠簡化錯誤恢復並使應用程序更加可靠。一個邏輯工做單元要成爲事務，必須知足所謂的ACID（原子性、一致性、隔離性和持久性）屬性。事務是數據庫運行中的邏輯工做單位，由DBMS中的事務管理子系統負責事務的處理。

事務的四大特性

原子性（Atomicity)

事務必須是原子工做單元；對於其數據修改，要麼全都執行，要麼全都不執行。好比轉帳，要麼轉帳成功，帳戶餘額增長（減小）；要麼轉帳失敗，帳戶餘額不變。

一致性(Consistency)

事務在完成時，必須使全部的數據都保持一致狀態。在相關數據庫中，全部規則都必須應用於事務的修改，以保持全部數據的完整性。事務結束時，全部的內部數據結構（如 B 樹索引或雙向鏈表）都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔，他們必須確保應用程序已強制全部已知的完整性約束。例如，當開發用於轉賬的應用程序時，應避免在轉賬過程當中任意移動小數點。

隔離性(Isolation)

由併發事務所做的修改必須與任何其它併發事務所做的修改隔離。事務查看數據時數據所處的狀態，要麼是另外一併發事務修改它以前的狀態，要麼是另外一事務修改它以後的狀態，事務不會查看中間狀態的數據。這稱爲隔離性，由於它可以從新裝載起始數據，而且重播一系列事務，以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將得到最高的隔離級別。在此級別上，從一組可並行執行的事務得到的結果與經過連續運行每一個事務所得到的結果相同。因爲高度隔離會限制可並行執行的事務數，因此一些應用程序下降隔離級別以換取更大的吞吐量。

持久性(Durability)

事務完成以後，它對於系統的影響是永久性的。該修改即便出現致命的系統故障也將一直保持。

例如咱們在使用JDBC操做數據庫時，在提交事務方法後，提示用戶事務操做完成，當咱們程序執行完成直到看到提示後，就能夠認定事務以及正確提交，即便這時候數據庫出現了問題，也必需要將咱們的事務徹底執行完成，不然就會形成咱們看到提示事務處理完畢，可是數據庫由於故障而沒有執行事務的重大錯誤。

併發事務帶來的問題

髒寫問題

當兩個或多個事務選擇同一行，而後基於最初選定的值更新該行時，會發生丟失更新問題。每一個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所作的更新，這將致使數據丟失。

例如，T1和T2同時修改一條數據，T2的修改覆蓋了T1的修改；若是在T1以後T2才能進行更改，則能夠避免該問題。

咱們來看一個經典的轉帳問題，開始小明和小剛都有1000元錢，在事務T1中，小明爲小剛轉帳100元，在事務T2中，小剛爲小明轉帳200元。則正常狀況下，結果爲：小明有1100元，小剛爲900元。若是發生了髒寫的問題，則結果可能爲：小明1200元，小剛800元。以下圖所示。

髒讀問題

一個事務正在對一條記錄作修改，在這個事務完成並提交前，這條記錄的數據就處於不一致狀態；這時，另外一個事務也來讀取同一條記錄，若是不加控制，第二個事務讀取了這些「髒」數據，並據此作進一步的處理，就會產生未提交的數據依賴關係。這種現象被形象地叫作」髒讀」。

例如：在事務T1中，小明爲小剛轉帳100元，在轉帳的過程當中，事務未提交或者未回滾時，此時事務T2讀取到了事務T1未提交的內容，也就是說在事務T2中讀取到了小明900元，小剛1100元的記錄。能夠用下圖表示。

不可重複讀問題

一個事務在讀取某些數據後的某個時間，再次讀取之前讀過的數據，卻發現其讀出的數據已經發生了改變！這種現象就叫作「不可重複讀」。

指事務T2讀取數據後，事務T1執行更新操做，使T2沒法讀取前一次結果。

例如，在事務T1中執行小明爲小剛轉帳100元的操做，在事務未提交以前，在事務T2中讀取的數據仍是小明爲1000元，小剛爲1000元。待事務T1提交後，事務T2中讀取的數據爲小明900元，小剛1100元。以下圖所示。

幻讀問題

一個事務按相同的查詢條件從新讀取之前檢索過的數據，卻發現其餘事務插入了知足其查詢條件的新數據，這種現象就稱爲「幻讀」。

事務t2讀取到了事務t1體提交的新增、刪除數據，不符合隔離性。

幻讀和不可重複讀都是讀取了另外一條已經提交的事務（這點就髒讀不一樣），所不一樣的是不可重複讀查詢的都是同一個數據項，而幻讀針對的是一批數據總體（好比數據的個數）。

例如，在事務T1中插入兩條分別爲小明和小剛的數據，在事務提交以前，事務T2中讀取的數據記錄爲10，隨後事務T1提交，則在事務T2中讀取的記錄爲12，以下所示。

併發事務問題的解決方案

爲了不上面出現的幾種狀況，在標準SQL規範中，定義了4個事務隔離級別，不一樣的隔離級別對事務的處理不一樣。如下四種不一樣的隔離級別限制由低到高，性能從高到底。

讀未提交

讀未提交（Read Uncommitted）：容許髒讀取，但不容許更新丟失。若是一個事務已經開始寫數據，則另一個事務則不容許同時進行寫操做，但容許其餘事務讀此行數據。該隔離級別能夠經過「排他寫鎖」實現。

不可避免 髒讀、不可重複讀、虛讀。

讀已提交

讀已提交（Read Committed）：容許不可重複讀取，但不容許髒讀取。這能夠經過「瞬間共享讀鎖」和「排他寫鎖」實現。讀取數據的事務容許其餘事務繼續訪問該行數據，可是未提交的寫事務將會禁止其餘事務訪問該行。

可避免 髒讀，不可避免 不可重複讀、虛讀。Oracle採用讀已提交。

可重複度

可重複讀取（Repeatable Read）：禁止不可重複讀取和髒讀取，可是有時可能出現幻讀數據。這能夠經過「共享讀鎖」和「排他寫鎖」實現。讀取數據的事務將會禁止寫事務（但容許讀事務），寫事務則禁止任何其餘事務。

可避免 髒讀、不可重複讀， 不可避免 虛讀。MySQL採用可重複讀。

序列化

序列化（Serializable）：提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接着一個地執行，不能併發執行。僅僅經過「行級鎖」是沒法實現事務序列化的，必須經過其餘機制保證新插入的數據不會被剛執行查詢操做的事務訪問到。

可避免 髒讀、不可重複讀、幻讀狀況的發生。

事務的四種隔離級別總結起來以下圖所示。

常看當前數據庫的事務隔離級別: show variables like 'tx_isolation';

設置事務隔離級別：set tx_isolation='REPEATABLE-READ';

Mysql默認的事務隔離級別是可重複讀，用Spring開發程序時，若是不設置隔離級別默認用Mysql設置的隔離級別，若是Spring設置了就用已經設置的隔離級別

重磅福利

關注「 冰河技術 」微信公衆號，後臺回覆 「設計模式」 關鍵字領取《深刻淺出Java 23種設計模式》PDF文檔。回覆「Java8」關鍵字領取《Java8新特性教程》PDF文檔。回覆「限流」關鍵字獲取《億級流量下的分佈式限流解決方案》PDF文檔，三本PDF均是由冰河原創並整理的超硬核教程，面試必備！！

好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一塊兒學習，一塊兒進步！！

寫在最後

若是你以爲冰河寫的還不錯，請微信搜索並關注「 冰河技術 」微信公衆號，跟冰河學習高併發、分佈式、微服務、大數據、互聯網和雲原生技術，「 冰河技術 」微信公衆號更新了大量技術專題，每一篇技術文章乾貨滿滿！很多讀者已經經過閱讀「 冰河技術 」微信公衆號文章，吊打面試官，成功跳槽到大廠；也有很多讀者實現了技術上的飛躍，成爲公司的技術骨幹！若是你也想像他們同樣提高本身的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公衆號吧，天天更新超硬核技術乾貨，讓你對如何提高技術能力再也不迷茫！