不可重複讀取Non-repeating Reads

意義:同個交易，重複讀取兩次的相同數據，會得到不一致的結果，因此也被稱為不一致讀
如何發生:

MySQL預設的可重複讀機制，行鎖會阻塞B交易的提交/回滾，直到A交易執行完成，因此用白話來說，只要不手賤去亂改，應該是不會發生這這種情況。

幻讀Phantom Read

在理解幻讀之前，先來複習一下之前髒讀、更新丟失、不可重複讀的概念

用幾個可能讓人心有戚戚焉的例子來比喻

1.Day14-髒讀，讀到另一交易未提交的數據，就像是工程師照著專案經理一開始的設計去做，結果經理卻提交給老闆另一個版本的設計，然後叫工程師重做。

2.Day15-更新丟失，最後提交的交易覆蓋先前提交的交易資料，在團隊開發時，因為有人忘記先把遠端拉下來，腦袋不清楚直接git push -f ，團隊專案被直接爆破。

3.不可重複讀取，在同一筆交易中，當一行數據獲取兩遍得到不同的結果，工程師被經理衝康多次終於受不了了，打算每做一個功能就去去問經理，結果每次問都獲得不一樣的回覆，笑死

4.幻讀，可以被理解成不可重複讀的特殊情況，不可重複讀是更新導致二次讀取異常，幻讀則是一交易新增、刪除資料表導致另一交易多次讀取數據異常，小名剛到職一家新公司，原本躊躇滿志打算做出一番大事業，當他在做後台時卻發現自己出現幻覺，資料會突然出現然後消失，問了之後才發現原來老闆喜歡自己連到資料庫亂刪除數據==

以上舉例純屬虛構，不代表任何人事物，亦不代表本人經歷，如有與現實雷同純屬巧合XD

併發控制

1.Read committed，禁止讀取更新時資料，解決髒讀
2.Repeatable read，禁止更新時讀取資料，解決不可重複讀取
3.可串行化（SERIALIZABLE），一個一個執行交易，因此不會出現上述併發問題

併發總結

MySQL的內建引擎與隔離機制，都有預設併發控制機制，如何取捨完全取決於業務需求，雖說最高級別的可序列化能夠避免全部的併發問題，不可避免會導致效能下降的問題。

預告

Day18-MySQL的資料類型