1、數據髒讀
事務a修改了某條數據，然後事務b讀取了事務a修改的該條數據，然後事務a由於某些原因，事務a回滾了，這樣事務b讀到的數據就和回滾的數據不同了，這時事務b讀取的數據就是髒數據。概況一句話就是一個事務讀取了另一個事務未提交的數據。
2、數據幻讀
事務a按一定條件讀取了該表的一些數據，然後事務b想該表插入了一些滿足事務a查詢條件的數據，當事務a再次以相同條件查詢數據時，會發現多出來一些數據，就好像產生了幻覺一樣，我們稱爲幻讀
3、不可重複讀
事務a讀取了某條數據，事務a沒有提交，然後事務b修改了該條數據，這時事務a再次讀取該條數據，這樣兩次讀取的數據不同，我們成爲該條數據爲不可重複讀。概況一句話就是一個事務多次讀取某條數據，發現讀取的數據不完全相同。
一、什麼是幻讀
在一次事務裏面，多次查詢之後，結果集的個數不一致的情況叫做幻讀。
而多或者少的那一行被叫做 幻行
二、爲什麼要解決幻讀
在高併發數據庫系統中，需要保證事務與事務之間的隔離性，還有事務本身的一致性。
三、MySQL 是如何解決幻讀的
如果你看到了這篇文章，那麼我會默認你瞭解了 髒讀 、不可重複讀與可重複讀。
1. 多版本併發控制（MVCC）（快照讀 / 一致性讀）
多數數據庫都實現了多版本併發控制，並且都是靠保存數據快照來實現的。
以 InnoDB 爲例，每一行中都冗餘了兩個字斷。一個是行的創建版本，一個是行的刪除（過期）版本。
具體的版本號（trx_id）存在 information_schema.INNODB_TRX 表中。
版本號（trx_id）隨着每次事務的開啓自增。
事務每次取數據的時候都會取創建版本小於當前事務版本的數據，以及過期版本大於當前版本的數據。
普通的 select 就是快照讀。
select * from T where number = 1;
原理：將歷史數據存一份快照，所以其他事務增加與刪除數據，對於當前事務來說是不可見的。
2. next-key 鎖 （當前讀）
next-key 鎖包含兩部分
記錄鎖（行鎖）
間隙鎖
記錄鎖是加在索引上的鎖，間隙鎖是加在索引之間的。（思考：如果列上沒有索引會發生什麼？）
select * from T where number = 1 for update;
select * from T where number = 1 lock in share mode;
insert
update
delete
原理：將當前數據行與上一條數據和下一條數據之間的間隙鎖定，保證此範圍內讀取的數據是一致的。
其他：MySQL InnoDB 引擎 RR 隔離級別是否解決了幻讀
引用一個 github 上面的評論 地址：
Mysql 官方給出的幻讀解釋是：只要在一個事務中，第二次 select 多出了 row 就算幻讀。
a 事務先 select，
b 事務 insert 確實會加一個 gap 鎖，但是如果 b 事務 commit，這個 gap 鎖就會釋放（釋放後 a 事務可以隨意 dml 操作），a 事務再 select 出來的結果在 MVCC 下還和第一次 select 一樣，接着 a 事務不加條件地 update，這個 update 會作用在所有行上（包括 b 事務新加的），a 事務再次 select 就會出現 b 事務中的新行，並且這個新行已經被 update 修改了，實測在 RR 級別下確實如此。
如果這樣理解的話，Mysql 的 RR 級別確實防不住幻讀
有道友回覆 地址：
在快照讀讀情況下，mysql 通過 mvcc 來避免幻讀。
在當前讀讀情況下，mysql 通過 next-key 來避免幻讀。
select * from t where a=1; 屬於快照讀
select * from t where a=1 lock in share mode; 屬於當前讀
不能把快照讀和當前讀得到的結果不一樣這種情況認爲是幻讀，這是兩種不同的使用。
mysql 的 rr 級別是解決了幻讀的。
先說結論，
MySQL 存儲引擎 InnoDB 隔離級別 RR 解決了幻讀問題。
如引用一問題所說，T1 select 之後 update，會將 T2 中 insert 的數據一起更新，那麼認爲多出來一行，所以防不住幻讀。看着說法無懈可擊，但是其實是錯誤的，InnoDB 中設置了 快照讀 和 當前讀 兩種模式，如果只有快照讀，那麼自然沒有幻讀問題，但是如果將語句提升到當前讀，那麼 T1 在 select 的時候需要用如下語法： select * from t for update (lock in share mode) 進入當前讀，那麼自然沒有 T2 可以插入數據這一回事兒了。
注意
next-key 固然很好的解決了幻讀問題，但是還是遵循一般的定律，隔離級別越高，併發越低。
擴展補充：
MySQL InnoDB支持三種行鎖定方式：
行鎖（Record Lock）:鎖直接加在索引記錄上面，鎖住的是key。
間隙鎖（Gap Lock）:鎖定索引記錄間隙，確保索引記錄的間隙不變。間隙鎖是針對事務隔離級別爲可重複讀或以上級別而已的。
Next-Key Lock ：行鎖和間隙鎖組合起來就叫Next-Key Lock。
鎖選擇
如果更新條件沒有走索引，例如執行”update from t1 set v2=0 where v2=5;” ，此時會進行全表掃描，掃表的時候，要阻止其他任何的更新操作，所以上升爲表鎖。
如果更新條件爲索引字段，但是並非唯一索引（包括主鍵索引），例如執行“update from t1 set v2=0 where v1=9;” 那麼此時更新會使用Next-Key Lock。使用Next-Key Lock的原因：
首先要保證在符合條件的記錄上加上排他鎖，會鎖定當前非唯一索引和對應的主鍵索引的值；
還要保證鎖定的區間不能插入新的數據。
如果更新條件爲唯一索引，則使用Record Lock（記錄鎖）。
InnoDB根據唯一索引，找到相應記錄，將主鍵索引值和唯一索引值加上記錄鎖。但不使用Gap Lock（間隙鎖）