MySQL中既存在redo log，又存在bin log，這是因為bin log是MySQL Server提供的一種歸檔日誌，其本身並不具備crash-safe能力。而redo log本身不具備歸檔能力，他是一種迴圈寫的日誌。 MySQL通過將這兩種日誌整合起來，並通過兩階段提交的機制，保證了數據... ...
前置知識
涉及到的幾個概念：隱藏欄位，undo log，readview
- (每個表中的)隱藏欄位：最後修改記錄的事務id，回滾指針
- undo log ：在插入/更新數據的時候記錄回滾日誌
- 當前讀：讀取的是記錄的最新版本，在執行的時候會加鎖，防止其他併發事務修改該記錄
select ... for update、update、insert、delete(排他鎖)都是一種當前讀 - 快照讀：讀取的可能是記錄的可見版本，可能是歷史記錄
對MVCC理解：
實現了事務隔離
每次開啟事務都會創建一個 read view ，以及回滾日誌 undo log，從而會形成一條回滾鏈
關閉事務那麼 read view 也會被關閉
回滾日誌何時被清除？
如果 read-view A 被關閉了，且 '將2改成1' 這個回滾日誌之前沒有 read-view 了，那麼此回滾日誌就可以被刪除
分析利用MVCC特性讀取同一個記錄的不同版本
對於同一個記錄，如果對它開啟了多次事務，就會產生如圖中的多個快照讀 A,B,C。
假設事務A,B,C分別對應於上述快照讀。由圖可知當前值為4，如果事務 A 需要讀取該記錄值，那麼需要由當前值 依次回滾 從而得到 1 這個值。
分析事務是否是隔離的
事務的隔離，指的就是多個事務的執行不會互相影響。具體點說，在 RR 隔離級別下，事務 A 在開啟後，多次讀取同一個記錄，讀取到的值始終是一致的。
從這個引出了一致性讀 (read-view) 這個概念。能夠保證事務 A 上述運行效果，依靠的是 MVCC (多版本併發控制) 這個概念。MVCC 通過 read-view，row_trx_id，回滾日誌，回滾鏈等保證了前後讀取的一致性，這是對於一個事務中只有查詢操作而言的。
在事務 A 開啟後，其實對整個庫進行了一次快照，但是這個快照並不是真正的整個資料庫數據，這太龐大了。而是由 活躍事務數組 來保證對全庫的快照。
活躍事務是指當前未提交的所有事務，通過這麼一個活躍數組，就達到了開啟事務後對全庫數據進行快照的效果。
從這個角度來看，事務是隔離的。因為這是站在只有查詢語句的視角。
而從下麵這個視角來看，事務是不隔離的。因為有當前讀這個概念。
有上述兩個事務，初始數據 （id,k）:（1,1），開啟事務 B
事務 C 更新後變成（1,2）
此時事務 B 才執行更新，而更新操作需要讀取此記錄的 當前值，也就是事務 B 讀取到了 （1,2），然後做更新；而後再次查詢，會發現（1,3）這種情況。
這樣看事務好像是非隔離的，因為事務 B 是先於事務 C 開啟的，它理應讀到 (1,1) 這樣的數據然後去做修改。
但是 MySQL 要保證不能丟失事務 C 的修改，且它已經提交了。所以可以得知：對於更新操作，是先讀後寫的，而且這個讀是當前讀（即該記錄的最新版本值），並且要獲取行寫鎖 ( X )。
