15 日誌和索引相關問題
1.在兩階段提交的不同瞬間，mysql如果發生異常重啓，是怎樣保證數據完整性的。
如果在圖中A的地方，也就是寫入redo log處於prepare階段之後，寫binlog之前，發生了崩潰（crash），由於此時binlog還沒寫，redolog還沒提交，所以崩潰恢復的時候。事務會回滾，這時，binlog還沒寫，所以不會傳到備庫。
時刻B，binlog寫完，redo log還沒commit前發生crash，崩潰恢復的mysql處理
1.如果redo log裏面是事務是完整的，也就是已經有了commit標識，則直接提交
2.如果redo log裏面的事務只有完整的prepare，則判斷對應的事務binlog是否存在並完整
A.如果是，則提交事務
B.否則，回滾事務
時刻B發生crash對應的就是2（a）的情況，崩潰恢復過程事務會被提交。
Q2.mysql怎麼知道binlog是完整的
一個事務的binlog是有完整格式的
Statement格式的binlog，最後會有COMMIT
Row格式的binlog，最後會有一個XID event
在5.6.2之後，還引入了binlog-checksum參數來驗證binlog內容的正確性
Q3：redo log和binlog是怎麼關聯起來的
因爲他們都有一個共同的數據字段，叫XID，崩潰恢復的時候，會按順序掃描redo log；
如果碰到既有prepare，又有commit的redo log，就直接提交
如果碰到只有prepare，而沒有commit的redo log，則拿着XID去binlog找對應的事務
Q4：處於prepare階段的redo log加上完整binlog，重啓就能恢復，mysql爲什麼這樣設計
爲了保證主庫和備庫的數據一致性
Q8：redo log一般設置多大
Redo log設置太小的話，會導致很快就寫滿，然後不得不強行刷redo log，這樣WAL機制的能力就發揮不出來了
所以，如果現在常見的幾TB的磁盤，直接將redo log設置爲4個文件，每個文件1GB。
Q9：正常運行的實例，數據寫入後的最終落盤，是從redo log更新過來的還是從buffer pool更新過來的。
實際上，redo log並沒有記錄數據頁的完整數據，所以並沒有能力自己更新磁盤數據頁
1.如果正常運行的實例，數據頁被修改後，跟磁盤的數據頁不一致，稱爲髒頁，最終數據落盤，就是把內存中的數據頁寫盤，這個過程與redo log 無關。
2.在崩潰恢復的情況下，InnoDB如果判斷到一個數據頁可能在崩潰恢復的時候丟失了更新，就會將他讀到內存，然後讓redo log更新內存內容，更新完成後，內存頁變成髒頁，回到第一種情況。
Q10：redo log buffer是什麼，是先修改內存，還是先寫redo log文件
Redo log buffer就是一塊內存，用來先存redo日誌的，也就是，在執行第一個insert的時候，數據的內存就被修改了，redo log buffer也寫入了內存中。
真正把日誌寫到redo log文件，是在執行commit語句的時候做的。