mysql 兩階段提交的不同瞬間，mysql 發生異常重啟，是怎麼保證資料完整性的
時刻a：binlog沒寫，不會傳到備庫里，redolog未提交，崩潰恢復的時候事務就會回滾
時刻b：如果redo log 已經由commit標識，直接提交。如果只有完整的prepare，則判斷binlog。
binlog完整則提交，否則回滾事務
1 mysql 怎麼知道binlog是完整的
statement格式的最後會有commit，row格式的最後會有乙個xid event，5.6之後可以用checksum的結果來看
2 redo log 和 binlog是怎麼關聯起來的
它們有乙個共同的資料字段，叫xid。崩潰恢復的時候，會按順序掃瞄redo log;
如果碰到既有prepare 、又有commit的redo log,就直接提交
如果碰到只有prepare,沒有commit的redo log，就拿著xid去binlog找對應的事務
3 處理prepare的redo log 加上完整的binlog，重啟就能恢復，mysql為什麼要這樣設計
binlog已經傳遞到從庫，為了保證主備一致，就需要主庫上也提交這個事務
4 為什麼要兩階段提交
事務的永續性問題：redo log 提交之後就不允許回滾，回滾會覆蓋其他事務，而redo log直接提交，然後binlog寫入的時候失敗，innodb又回滾不了，資料和binlog日誌又不一致了，兩階段提交就是給所有人乙個機會，當每個人說我ok的時候，再一起提交
5 只用binlog 來支援崩潰恢復，可行嗎
不可行，現在binlog的能力，還不夠支援崩潰恢復
如果發生了crash，那麼事務1也可能會丟失
6 那能不能反過來，只用redo log，不要binlog
如果只是崩潰恢復的話可以，但是歸檔還是要用binlog的
7 正常執行中的例項，資料寫入後的最終落盤，是從redo log更新過來的，還是從buffer pool更新過來的呢？
redo log 並沒有紀錄資料頁的完整資料，所以沒有能力去更新磁碟資料頁，
1 資料頁被修改，跟磁碟資料不一致，稱為髒頁，資料落盤是通過記憶體中的資料頁寫盤。
2 崩潰恢復中，innodb 判斷乙個資料頁可能在崩潰恢復的時候丟失了更新，就會將它讀到記憶體，然後讓redo log更新記憶體內容，更新完成後，就會到了第一種狀態
8 redo log buffer是什麼？是先修改記憶體還是先寫redo log檔案
沒commit的時候寫入 buffer中，commit的時候會 寫入redo log
MySQL日誌及索引
mysql物理結構 mysql它是通過檔案系統對資料進行儲存和管理，從物理結構上分為日誌檔案和資料檔案 日誌檔案 錯誤日誌 err log 預設是開啟狀態的，如果是5.5.7版本以後的是無法關閉錯誤日誌，錯誤日誌它記錄了執行過程中遇到的所有嚴重的錯誤資訊，以及mysql每次啟動和關閉的詳細資訊。預設...
mysql索引要素 mysql索引和索引的原理
首先為什麼要加索引？資料庫伺服器有兩種儲存介質，我們需要把索引放到硬碟上，在硬碟上進行查詢時會產生i o 操作 我們通過索引來查詢某 資料的時候，需要計算產 的磁碟 i o 次數，當磁碟 i o 次數越多，所消耗的時間也就越 如果我們能讓索引的資料結構儘量減少硬碟的 i o操作，所消耗的時間也就越 ...
mysql索引和事務 MySql索引和事務
mysqlde 索引 目的 是為了加快查詢的速度,避免順序查詢,但是拖慢了插入和刪除的速度.應用在在經常查詢,很少少出插入的場景中.結構 b 樹,n叉搜尋樹,使用鏈式的結構把每一層的節點連線在一起,葉子節點中儲存資料,非葉子節點輔助查詢.主鍵索引和其他索引的不一樣 主鍵索引葉子節點儲存一條一條的資料...