MySQL中binlog是什麼東西？
回顧上一篇的内容
在上一篇文章中，介紹了一下InnoDB引擎的架構，還說了三種redo log日志的輸盤的政策
接下來，我們繼續上一講的内容來探尋一下MySQL中的binlog究竟是什麼。
binlog是什麼?
在上一講裡，我們了解了redo log，偏向實體性質，它記錄了對哪個資料頁的哪個記錄進行了個什麼修改，
是屬于InnoDB所特有的
，記住，這一點希望大家牢記。
而binlog被稱為歸檔日志，裡面也記錄了所作的操作，不過稍微有點不同的是偏向邏輯性的，類似于“對users表中id=10的資料做了更新操作，更新後的值是‘小明’ ”，
它是屬于MySQL Server自己的日志檔案
是以，在送出事務的時候同，不但會把redo log寫入到磁盤中去，并且也會将此次操作對應的binlog日志寫入到磁盤檔案中去，需要注意的是，binlog日志寫入磁盤它是不經過InnoDB引擎的
和之前說的redo log刷盤政策類似，binlog日志也有刷盤政策，你可以通過下面的方式去看一下自己所使用的MySQL預設使用的是哪種方式
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
1 row in set (0.02 sec)
-
sync_binlog=0
此時你把binlog寫入到磁盤的時候，其實并不是直接進入到磁盤中去，而是進入到了os cache記憶體緩存中
-
sync_binlog=1
當你送出事務的時候，會強制把binlog寫入到磁盤中去，哪怕送出事務後當機了，磁盤上的binlog資料也不會丢失
有了binlog後是如何完成事務的送出的？
在最後送出事務的時候，會将此次事務對應的binlog檔案的檔案名和路徑寫入到redo log中去，并且寫入一個commit标記，在完成上述操作之後，事務才算是完成了送出
到這裡你也許會問，為什麼要加上這最後一步？
其實這一步的目的是為了保證redo log和binlog資料一緻，如果說隻完成了第5步或者隻完成了第5 6步，隻要是還沒執行第7步的時候突然當機了，那麼此次事務将會被判定為事務送出失敗，因為redo log裡面沒有commit标記
在送出事務後髒資料是如何刷入記憶體的呢？
當發生一次更新的時候，一旦事務送出成功，redo log日志中就會有相應的資料并且會由commit标記，不管系統是否當機，都不會出現資料丢失的情況，很容易想到的是，磁盤中的資料也一定是早晚需要更新的，但是，是怎麼更新的呢？
MySQL中有一個IO線程會專門負責将髒資料不定時地刷入到磁盤中，它會挑一個資料庫壓力不是那麼大的時候進行這些操作
講到這裡，InnoDB的基本架構就差不多了，回顧之前講過的内容，你有想過為什麼在進行更新操作的時候不是直接修改磁盤上的檔案而是通過Buffer Pool、undo log、redo log、binlog、送出事務、髒資料這麼多東西來完成資料的更新？
接修改磁盤上的檔案而是通過Buffer Pool、undo log、redo log、binlog、送出事務、髒資料這麼多東西來完成資料的更新？
我相信大部分小夥伴都能說出來為什麼，因為，我們進行更新操作的時候，對于磁盤來說是進行随機讀寫，如果直接對磁盤上的資料進行操作的話，速度是非常慢的，但是，将資料緩存到Buffer Pool在中然後基于記憶體來對其進行修改則會将速度提高非常之多，再通過寫redo log、binlog日志的方式來保證資料的安全性，也許你會想，寫redo log和binlog不也是向磁盤寫資料嗎？難道效率不會很低嗎？但是，這雖然是對磁盤進行操作，但是确實順序讀寫的方式，比起随機讀寫，磁盤的順序讀寫的效率是非常之高的。是以，InnoDB引擎，通過上面這些看似繁雜的步驟，換來的卻是MySQL資料庫的高并發性能