目錄
不可重複讀（修改）：同一事務同一條件下，無法讀取到，修改後已提交之前的數據
幻讀（新增或刪除）：同一事務同一條件下，讀取到的記錄數不一樣
以下文章來源於公衆號：後端技術學堂 ，作者LemonCoder
大部分人學習和工作中用慣了CRUD，對面試官刨根問底的靈魂拷問你還能對答如流嗎？我們有必要了解一些更深層次的數據庫基礎原理。
整理了面試中，關於MySQL事務和存儲引擎10個FAQ（Frequently asked questions），你想知道的都在這裏。
什麼是事務？
事務就是「一組原子性的SQL查詢」，或者說一個獨立的工作單元。如果數據庫引擎能夠成功地對數據庫應用該組查詢的全部語句，那麼就執行該組查詢。如果其中有任何一條語句因爲崩潰或其他原因無法執行，那麼所有的語句都不會執行。也就是說，事務內的語句，要麼全部執行成功，要麼全部執行失敗。
事務控制語法知道嗎？
1、BEGIN 或 START TRANSACTION 顯式地開啓一個事務；
2、COMMIT / COMMIT WORK二者是等價的。提交事務，並使已對數據庫進行的所有修改成爲永久性的；
3、ROLLBACK / ROLLBACK WORK。回滾會結束用戶的事務，並撤銷正在進行的所有未提交的修改；
4、SAVEPOINT identifier 在事務中創建一個保存點，一個事務中可以有多個 SAVEPOINT；
5、RELEASE SAVEPOINT identifier 刪除一個事務的保存點；
6、ROLLBACK TO identifier 把事務回滾到標記點；
7、SET TRANSACTION 用來設置事務的隔離級別。
InnoDB 存儲引擎提供事務的隔離級別有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE
用通俗的語言說說你理解的事務
用銀行業務舉個栗子，用戶lemon有兩銀行卡，一張是招商銀行CMBC的工資卡，另一張是工商銀行ICBC的儲蓄卡，每月10號發工資都要把招行卡的100萬轉到建設銀行儲蓄卡賬戶。記住這裏的銀行縮寫後面就是對應的數據表名稱，你要記不住，我給你理一理。
1、招商銀行（CMBC）：“存麼？白癡！”
2、中國工商銀行（ICBC）： “愛存不存！”
3、中國建設銀行（CCB）： “存？存不？”
4、中國銀行（BC）： “不存！”
5、中國農業銀行（ABC）： “啊，不存！”
6、民生銀行（CMSB）：“存麼？SB！"
7、興業銀行（CIB）：“存一百。”
8、國家開發銀行（CDB）：“存點吧！”
9、匯豐銀行（HSBC）：“還是不存！”
這個轉賬的操作可以簡化抽成一個事務，包含如下步驟：
- 查詢CMBC賬戶的餘額是否大於100萬
- 從CMBC賬戶餘額中減去100萬
- 在ICBC賬戶餘額中增加100萬
以下語句對應創建了一個轉賬事務：
1、START TRANSACTION;
2、SELECT balance FROM CMBC WHERE username='lemon';
3、UPDATE CMBC SET balance = balance - 1000000.00 WHERE username = 'lemon';
4、UPDATE ICBC SET balance = balance + 1000000.00 WHERE username = 'lemon';
5、COMMIT;
事務的ACID特性是什麼？
ACID其實是事務特性的英文首字母縮寫，具體的含義是這樣的：
- 原子性（atomicity)
一個事務必須被視爲一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作。
- 一致性（consistency)
數據庫總是從一個一致性的狀態轉換到另外一個一致性的狀態。在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，CMBC賬戶中也不會損失100萬，不然lemon要哭死，因爲事務最終沒有提交，所以事務中所做的修改也不會保存到數據庫中。
- 隔離性（isolation)
通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時如果有其他人準備給lemon的CMBC賬戶存錢，那他看到的CMBC賬戶裏還是有100萬的。
- 持久性（durability)
一旦事務提交，則其所做的修改就會永久保存到數據庫中。此時即使系統崩潰，修改的數據也不會丟失。持久性是個有點模糊的概念，因爲實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必。而且「不可能有能做到100%的持久性保證的策略」否則還需要備份做什麼。
什麼是髒讀、不可重複讀、幻讀
髒讀：讀取到，修改後未提交的數據
在事務A修改數據之後提交數據之前，這時另一個事務B來讀取數據，如果不加控制，事務B讀取到A修改過數據，之後A又對數據做了修改再提交，則B讀到的數據是髒數據，此過程稱爲髒讀Dirty Read。
不可重複讀（修改）：同一事務同一條件下，無法讀取到，修改後已提交之前的數據
一個事務內在讀取某些數據後的某個時間，再次讀取以前讀過的數據，卻發現其讀出的數據已經發生了變更、或者某些記錄已經被刪除了。
幻讀（新增或刪除）：同一事務同一條件下，讀取到的記錄數不一樣
事務A在按查詢條件讀取某個範圍的記錄時，事務B又在該範圍內插入了新的滿足條件的記錄，當事務A再次按條件查詢記錄時，會產生新的滿足條件的記錄（幻行 Phantom Row）
不可重複讀與幻讀有什麼區別？
- 不可重複讀的重點是修改：在同一事務中，同樣的條件，第一次讀的數據和第二次讀的「數據不一樣」。（因爲中間有其他事務提交了修改）
- 幻讀的重點在於新增或者刪除：在同一事務中，同樣的條件，第一次和第二次讀出來的「記錄數不一樣」。（因爲中間有其他事務提交了插入/刪除）
四個隔離級知道嗎？解決了什麼問題
SQL實現了四個標準的隔離級別，每一種級別都規定了一個事務中所做的修改，哪些在事務內和事務間是可見的，哪些是不可見的。低級別的隔離級一般支持更高的併發處理，並擁有更低的系統開銷。
各個隔離級別可以不同程度的解決髒讀、不可重複讀、幻讀。隔離級別各有所長，沒有完美的解決方案，脫離業務場景談具體實施都是耍流氓。
MySQL中哪些存儲引擎支持事務？
MySQL中InnoDB和NDB Cluster存儲引擎提供了事務處理能力，以及其他支持事務的第三引擎。
什麼是自動提交？
MySQL默認採用自動提交AUTOCOMMIT模式。也就是說，如果不是顯式地開始一個事務，則每個查詢都被當作一個事務執行提交操作。
對於MyISAM或者內存表這些非事務型的表，修改AUTOCOMMIT不會有任何影響。對這類表來說，沒有COMMIT或者ROLLBACK的概念，也可以說是相當於一直處於AUTOCOMMIT啓用的模式。
在事務中可以混合使用存儲引擎嗎？
儘量不要在同一個事務中使用多種存儲引擎，MySQL服務器層不管理事務，事務是由下層的存儲引擎實現的。
如果在事務中混合使用了事務型和非事務型的表（例如InnoDB和MyISAM表）,在正常提交的情況下不會有什麼問題。
但如果該事務需要回滾，非事務型的表上的變更就無法撤銷，這會導致數據庫處於不一致的狀態，這種情況很難修復，事務的最終結果將無法確定。所以，爲每張表選擇合適的存儲引擎非常重要。
MySQL存儲引擎類型有哪些？
最常用的存儲引擎是InnoDB引擎和MyISAM存儲引擎，InnoDB是MySQL的默認事務引擎。
查看數據庫表當前支持的引擎 ：
1、show table status from 'your_db_name' where name='your_table_name';
2、查詢結果表中的`Engine`字段指示存儲引擎類型。
InnoDB存儲引擎的特點和應用場景？
InnoDB是MySQL的默認「事務引擎」，被設置用來處理大量短期（short-lived）事務，短期事務大部分情況是正常提交的，很少會回滾。
更多InnoDB事務模型相關，參考MySQL官方手冊，這裏貼一下鏈接：
https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-model.html
- 歷史
現代MySQL版本中的InnoDB在歷史上叫InnoDB plugin，這個MySQL插件在2008年被開發出來，直到2010在Oracle收購了Sun公司後，發佈的MySQL5.5才正式使用InnoDB替代了舊版本的InnoDB plugin，至此 「備胎」成功轉正成爲MySQL的御用引擎而不再是插件，你看一個插件都這麼努力。
- 特點
- 採用多版本併發控制（MVCC，MultiVersion Concurrency Control）來支持高併發。並且實現了四個標準的隔離級別，通過間隙鎖
next-key locking策略防止幻讀的出現。- 引擎的表基於聚簇索引建立，聚簇索引對主鍵查詢有很高的性能。不過它的二級索引
secondary index非主鍵索引中必須包含主鍵列，所以如果主鍵列很大的話，其他的所有索引都會很大。因此，若表上的索引較多的話，主鍵應當儘可能的小。另外InnoDB的存儲格式是平臺獨立。- InnoDB做了很多優化，比如：磁盤讀取數據方式採用的可預測性預讀、自動在內存中創建hash索引以加速讀操作的自適應哈希索引（adaptive hash index)，以及能夠加速插入操作的插入緩衝區（insert buffer)等。
- InnoDB通過一些機制和工具支持真正的熱備份，MySQL的其他存儲引擎不支持熱備份，要獲取一致性視圖需要停止對所有表的寫入，而在讀寫混合場景中，停止寫入可能也意味着停止讀取。
MyISAM存儲引擎的特點和應用場景？
MyISAM是MySQL 5.1及之前的版本的默認的存儲引擎。MyISAM提供了大量的特性，包括全文索引、壓縮、空間函數（GIS)等，但MyISAM不「支持事務和行級鎖」，對於只讀數據，或者表比較小、可以容忍修復操作，依然可以使用它。
- 特性
- MyISAM「不支持行級鎖而是對整張表加鎖」。讀取時會對需要讀到的所有表加共享鎖，寫入時則對錶加排它鎖。但在表有讀取操作的同時，也可以往表中插入新的記錄，這被稱爲併發插入。
- MyISAM表可以手工或者自動執行檢查和修復操作。但是和事務恢復以及崩潰恢復不同，可能導致一些「數據丟失」，而且修復操作是非常慢的。
- 對於MyISAM表，即使是
BLOB和TEXT等長字段，也可以基於其前500個字符創建索引，MyISAM也支持「全文索引」，這是一種基於分詞創建的索引，可以支持複雜的查詢。- 如果指定了
DELAY_KEY_WRITE選項，在每次修改執行完成時，不會立即將修改的索引數據寫入磁盤，而是會寫到內存中的鍵緩衝區，只有在清理鍵緩衝區或者關閉表的時候纔會將對應的索引塊寫入磁盤。這種方式可以極大的提升寫入性能，但是在數據庫或者主機崩潰時會造成「索引損壞」，需要執行修復操作。
InnoDB與MyISAM對比
說了這麼多估計看一眼也沒記住，給你一張表，簡單羅列兩種引擎的主要區別，如下圖。
其他存儲引擎
MySQL還支持其他一些存儲引擎，比如memory引擎、NDB集羣引擎、CSV引擎，由於這些引擎沒有上述InnoDB 和MyISAM 常用，這裏不作介紹，感興趣可以去翻MySQL文檔瞭解。這裏同樣給出官方鏈接：
https://dev.mysql.com/doc/refman/5.7/en/storage-engines.html
再說兩句
這一篇是MySQL基礎篇，我力求用通俗易懂和圖表結合的形式給大家梳理這塊知識，越是基礎和底層的知識越容易被考察掌握程度，以上知識點都可能成爲面試中的一個考察點，相信看完對MySQL事務和存儲引擎應該有一個比較完整的理解。