重做日志與二進制日志

MySQL 中有六種日志文件，
分別是：重做日志（ redo log ）、回滾日志（ undo log ）、二進制日志（ binlog ）、錯誤日志（ errorlog ）、慢查詢日志（ slow query log ）、一般查詢日志（ general log ），中繼日志（ relay log ）。
其中重做日志和回滾日志與事務操作 息息相關 ，二進制日志也與事務操作有一定的關系，這三種日志，對理解 MySQL 中的事務操作有著重要的意義。
這里簡單總結一下這三者具有一定相關性的日志。
 
重做日志（ redo log ）

作用：
　　確保事務的持久性。
　　防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟 mysql 服務的時候，根據 redo log 進行重做，從而達到事務的持久性這一特性。
內容：
　　物理格式的日志，記錄的是物理數據頁面的修改的信息，其 redo log 是順序寫入 redo log file 的物理文件中去的。
什么時候產生：
　　事務開始之后就產生 redo log ， redo log 的落盤并不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入 redo log 文件中。
什么時候釋放：
　　當對應事務的臟頁寫入到磁盤之后， redo log 的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。
對應的物理文件：
　　默認情況下，對應的物理文件位于數據庫的 data 目錄下的 ib_logfile1&ib_logfile2
　　 innodb_log_group_home_dir 指定日志文件組所在的路徑，默認 ./ ，表示在數據庫的數據目錄下。
　　 innodb_log_files_in_group 指定重做日志文件組中文件的數量，默認 2
　　關于文件的大小和數量，由一下兩個參數配置
　　 innodb_log_file_size 重做日志文件的大小。
　　 innodb_mirrored_log_groups 指定了日志鏡像文件組的數量，默認 1
其他：
　　很重要一點， redo log 是什么時候寫盤的？前面說了是在事物開始之后逐步寫盤的。
　　之所以說重做日志是在事務開始之后逐步寫入重做日志文件，而不一定是事務提交才寫入重做日志緩存，
　　原因就是，重做日志有一個緩存區 Innodb_log_buffer ， Innodb_log_buffer 的默認大小為 8M( 這里設置的 16M),Innodb 存儲引擎先將重做日志寫入 innodb_log_buffer 中。

　　然后會通過以下三種方式將 innodb 日志緩沖區的日志刷新到磁盤
　　 1 ， Master Thread 每秒一次執行刷新 Innodb_log_buffer 到重做日志文件。
　　 2 ，每個事務提交時會將重做日志刷新到重做日志文件。
　　 3 ，當重做日志緩存可用空間 少于一半時，重做日志緩存被刷新到重做日志文件
　　由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于第一種方式， Innodb_log_buffer 到重做日志文件是 Master Thread 線程的定時任務。
　　因此重做日志的寫盤，并不一定是隨著事務的提交才寫入重做日志文件的，而是隨著事務的開始，逐步開始的。
　　另外引用《 MySQL 技術內幕 Innodb 存儲引擎》（ page37 ）上的原話：
　　即使某個事務還沒有提交， Innodb 存儲引擎仍然每秒會將重做日志緩存刷新到重做日志文件。
　　這一點是必須要知道的，因為這可以很好地解釋再大的事務的提交（ commit ）的時間也是很短暫的。

回滾日志（ undo log ）

作用：
　　保存了事務發生之前的數據的一個版本，可以用于回滾，同時可以提供多版本并發控制下的讀（ MVCC ），也即非鎖定讀

內容：
　　邏輯格式的日志，在執行 undo 的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同于 redo log 的。

什么時候產生：
　　事務開始之前，將當前是的版本生成 undo log ， undo 也會產生 redo 來保證 undo log 的可靠性

什么時候釋放：
　　當事務提交之后， undo log 并不能立馬被刪除，
　　而是放入待清理的鏈表，由 purge 線程判斷是否由其他事務在使用 undo 段中表的上一個事務之前的版本信息，決定是否可以清理 undo log 的日志空間。

對應的物理文件：
　　 MySQL5.6 之前， undo 表空間位于共享表空間的回滾段中，共享表空間的默認的名稱是 ibdata ，位于數據文件目錄中。
　　 MySQL5.6 之后， undo 表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成數據庫初始化后生效且不可改變 undo log 文件的個數
　　如果初始化數據庫之前沒有進行相關配置，那么就無法配置成獨立的表空間了。
　　關于 MySQL5.7 之后的獨立 undo 表空間配置參數如下
　　 innodb_undo_directory = /data/undospace/ --undo 獨立表空間的存放目錄
　　 innodb_undo_logs = 128 -- 回滾段為 128KB
　　 innodb_undo_tablespaces = 4 -- 指定有 4 個 undo log 文件

　　如果 undo 使用的共享表空間，這個共享表空間中又不僅僅是存儲了 undo 的信息，共享表空間的默認為與 MySQL 的數據目錄下面，其屬性由參數 innodb_data_file_path 配置。
　　 Dns8b+B7Z/2gQ8IoEhEij8xJ6sOF/wam1eOsX4Mnm9ySPSdcBuB0ynI+zUpg8HXvAMvXVI1xflyVlxftkGKtn8ZOp/f5ANJWmatiHdIFWvX2T0Ji5tn1l/mpY/Mn1XPiHdLKZvm5tlLPs3G4zn8aau3Qqz9we10czcSKY5nWtf3uLbTSmL36ZEyuRL27ci/q34sjZAHbDZhJjPp9YmKbZ/01ZiuTICZfFbVp7pzQlYD8f5gJybLG51A4P2mxtE2Ad0LNziL+O/n/jv/jZy80GeJUmABEiABEjgJggU3ka+Cc/pJAmQAAmQAAl8E4HOdyN/k93DqsZ6llZkmvHiiaJsppEACZAACVw1Aa5sr7p56RwJkAAJkMAQCPCZ7RBagTaQAAmQAAlcNQEOtlfdvHSOBEiABEhgCAQ42A6hFWgDCZAACZDAVRPgYHvVzUvnSIAESIAEhkCgeLB1vP5eSzgEr2kDCVQRYPxX0WHetRNg/PfSwsWDbS9VUSkJkAAJkAAJ3CYBDra32e70mgRIgARI4BsJpP/OtuLFDFUfCkhflF73In/mF31ogfz0Cz8uHB+M/8IPgTA+BxKftR9iadl/auP/G0elK64q9yECON7Rdyf5dPTzguZbfNk3fR5wLDH+2fdv+VrH+O8l/nkb+YpnUXSNBEiABEhgGAQ42A6jHWgFCZAACZDAFRNIn9lesZN0jQRIgARIgAQuSYAr20vSZ90kQAIkQAI3QYCD7U00M50kARIgARK4JAEOtpekz7pJgARIgARuggAH25toZjpJAiRAAiRwSQIcbC9Jn3WTAAmQAAncBAEOtjfRzHSSBEiABEjgkgQ42F6SPusmARIgARK4CQKFg+3E9Vt9Ys/xglby3ZCXd4UGCHxXqRObgsCHO+lGO9S7SlP9XWntQk/kq/gb/ec5ttay9pF21zJ+d6Dsyns607ZnfT2nuj7i//T4s+P3HD/OkdGxc27718m7fhqX0jcdr8s+eY7H1ypzfvy0jf9rJdqFX7n3QE5c/0rejewcPd9N/HN9/+hOunwnr62/yfuOXd87On2+d3XiHn3D5yY2ZcsMuf2r+IndntO+ffvy//T4+974Er8Dzzme+270OnnHC6zriiofdN0nq9u/Kn6y/aCP8++t//T4EZ/7iv8+eP4knf90MVprHTIjepuP1Olh8xuL9V5nQeftdjtMp9M4XX9RA7X5WpHMjOMqkH6RJM7NfLlit1ppsfT3lwv/bY7YSmx+L2CYmZYrOqrT73gInrVvgMXAlA0CPMf6oy8qxSdV8kX2ZNJkVaGrD4J5lHvYYLZYq2PdBnJi2ZbRU3pq+hApSXSXysQZUbsdsNmEmM81o4PNv8p/s+4yflLXnQs/0O2bxledfV3kN+JbFX+mjxLd2fhty6dKHsB+vcBMQDgPFTj012XybCvlJy4exxssluk1QZWPQtOor1w/KuzX7HV/0n0hiXOTbUX8nHJ9gdG3YOhXNkBfC+IYh4HdKavf0KGAGPoT/0qun6p8Rj4XPwZlHl6GQLLy07OEtjObMvloJpuu7LLl6vJd354Zyww8SFZxztGzZslyHhj5OIp8YJaRVWCQ2qP9L/6t1w/HsVatUl92pVU5s20gX2ybMZtvsLLNcs/qLMvPrsxUeyX8DRtKVu4Rf4N3ln8D/6v4RfGTrpTK/Mj6mz0/V07rKZOvjr8BxVflV1/iflXVb4rki9IK46RCf018CHervxXUWRU/0j7W186s64tcP9LYkraW+tLrD45Q8RyXUcen9f86/ao+g7sdZw3ip5B3vt/aevP5Os75exqbTle2TeYKu9US27jg/isE7myp0vyJi/twZa2WsV1i9SDPfNZY/3rAePOKdOK8xfL3HfyXrH5jJbtf43Xj48kBttoou3h75jTQ/3mHR2PWKsK7VEP9UVv5+hrOLyH8RyOM3gLEa+ZY1xjySLgOn67YbF9k+Xfg/26Vtm9RfGk7LvVr2mf5j58SX1ssZ01bu4yyXr3G+bsVZkuts0J/B/FRZpGsTCuvL2gQ//s1Fr8BX/URWdHOTrpr1qR/mf3Hiu8m16dS55nxHQS+fbD9DqfK6zgg/CzPbZfjwHu7x4fRweTWz1NjpW3lG1d0XsH9F8LDBov4lvR5Sqr4D9z/8xzOSFX5nymaO23Lp618zqDTEj5D4OGX3KxWUzM9YMsGqbs/eqCtUnlh+5vG/69x/IhqhLF2t8otnddUvy7P3x9HoHA38iC92K/xMX7M7CZ28DD+iGaP23eE8ye1ytL2O0/62Z1OGWH+Eu1OVikTFy/zEO9N+nqd/skdxofYFlGudEdPhnXt0e8Yd3pHtDyDCrzI5sbytrbvO9viPZy33GWe4Q/g3/uYf2P/S/h9H4gWNWX8N+Pvx8RXvMtVx21TGoX9t0i4RH/D+BjrziXPL/UGBquakvgptM+4vqA+/mVyHTwDq9kMs9kKeC76Vxkl9TfQb7mRPamLn2x5nn87gcJP7EnQvODVvmVba1rm1lBSPtpI8WlsnrI3EESbdV7xkmyuKspXm60yGwCkCr0hQlWX2UCB3Q676RTTwwarcI7n6UGSMJ3qQTCzQSexueSgQr9sQtKbGCLptK5yG+1NJo3kS0yTZHtzR1wwuUVX3T5b9U+ZnqG3LqXV2Dbm67DzU7n8kev7GIcmf3ujViP/rTZI6zZlS+Mnb1JhiujqOv6hNq+lMRFVnIk/yzcJ7jR+vyO+9KYiC4qxSSdK13GUstfla+UL+i+S+Ey0wAskDvP6zTYGUpZJ/7L0p5vxkk1SUoXFOFOHJR/Zk+iOzSuL/7rrW7JZtKr+wj4c2dhIv6U7Hz+acN3vefFfp5X5QqDzDVJFOpmW53xrTLIbQIbqPzeIMFaHGpvfYRfjv5/4/zm3kTkx+tEEohXBCPO3Yb4I5EfDpfEkQAKDJ1B4G3nwVtNAEiABEiABEvhBBG5sN3JJyxQ8q7FLZp7t2Jn9n9G+/hmzBhIgARLokQBXtj3CpWoSIAESIAESEAJ8Zss4IAESIAESIIGeCXCw7Rkw1ZMACZAACZAAB1vGAAmQAAmQAAn0TICDbc+AqZ4ESIAESIAEigdbx2v5Wj6CJYEfTIDx/4Mbj6a3JsD4b42wSEHxYFtUkmkkQAIkQAIkQAJnEeBgexY2CpEACZAACZBAcwLpv7OteHFC9DJu/QLyrHL9wgfmRy9QJx+bwA+JD8Z//AEAu/Xki8yrmXyDmv37qvt3bfxn44Ln5xDIfYgAjnf03Uk+veCjBd/xYmzW0c+Lscm1hCvjn33/lq91jP9e4p+3kc+ZnlCGBEiABEiABE4gwMH2BFgsSgIkQAIkQALnEEif2Z4jTRkSIAESIAESIIFaAlzZ1iJiARIgARIgARJoR4CDbTt+lCYBEiABEiCBWgIcbGsRsQAJkAAJkAAJtCPAwbYdP0qTAAmQAAmQQC0BDra1iFiABEiABEiABNoR4GDbjh+lSYAESIAESKCWAAfbWkQsQAIkQAIkQALtCOQGW8cLEATBj/7Envjgu5N2ZH6AtOv7yLo5cX3VftKGgeec7EWd/KDjQ97v6rsn+0wBEiABEvgOAsl7ICeufww858h4I5e8M7eD96W6vnd0OtAjbaTaytQlab6btKfjBUfPOcGXGvmfEB8n+2zy43ESO3xv9gn9hnHDuGkQA/+Yo/l+vcBMEpwHM7nxsesHmI+Aw+Y3XvGCNzlJvhoSqdFlojP9RREgSd+tMFtuVbasop6nEIWYLda1dsiqLKozsmGx3icyOm+322E6FaXyl9YfJ9T+JHZKycMBB3xgoW3LfjnDtNvMCwI8xzVFX1SqrTZXwH2cYvd3aaU7D2NsXtO07Z8NHp8cYBvxtAoXnNTJt40PqfJsfrG9SUzI+WGDDe6B1wV0UyufX1xgWx8vBQiYRAIkQAK9EcjPStp89UFWR0GQrrAcL1lduX5gf03IXElN3KMvq+rMDMHx/KM7OW2WKSuwoq8WqZVZkK4sy8plbdDn2fKyijJXkq5v26rqM1aaoqebla1z9Aw/tH05VsI0U78uW/TbWP7M+GjLT/E2YkTxDWzmgLDJpp0WP0VsmEaGjAHGQJsYsFa2XQ3nsrJNVpXbJdRaa+LiPlyl6VLZdonVgzx3XGO9X+Nj7MHBFneyQoasZr/wMP7AMl2gtjZxt5Jvc0Z/+68QuGuucr/+izB4QzDXMrIyjldQ4t9ohNGb2G7+jSFPTnWdZs7Zx5M7jM8WvpxgO34OHsYSEylJtdLOLWC3CA/PGP8C0GHcXI4aayYBErgGAr0MtueC+QrHuJs4GGODVXgP1wHG4de56nqQ22I5Sy/2cDwEvout3EbefyE8bNJbyj3UXq9ylB9kTuLXVr7OwqHzq7Of+SRAAiRwHoHcbuTz1DSQUivXx8zuWVmtfKTP295DjJ8eMP74D9v3EPeP9wjfjcGtQTV9Fina/YtkMNviPZw32AUtE4rYShmsA1nNn/gnA3uBiDyvTJUDztO8gJ8DT3YqF9TbTL6g4oZJ7fgV8Y18sTddOxiPDgg/GxrFYiRAAiTwDQSsla21+QTT6Hapucmn0iC58D0j2noUy8oWpNUM8X4nrF8/4Gdus0p+8vcZYvx8j48/e2D/jvD58YSLplm/aNS3e6NNUJ/J5qkAHmZYwkOgdl9N4cO47Z0YU3QwwtyyX3Snk4HtcqZugae3mUWHvQlr/TdEkOiw84pqLE6LbpU+ZPc+7dcIX4L0NrdsNkvNK1ZlptbIt4sPqagdvyK+ZnwpV+QW+6HbRw8mIh7TAAmQwDkE+D3bc6gNQUZWxQ/vyc7tIZg0BBtkQvDwnk7whmATbSABEiCB77uNTNbdEtgusRlnb8t3W8WP0zZx8TjeJHdSfpz9NJgESOBqCXBle7VNS8dIgARIgASGQoAr26G0BO0gARIgARK4WgIcbK+2aekYCZAACZDAUAhwsB1KS9AOEiABEiCBqyXw/0ZKbqIR53gdAAAAAElFTkSuQmCC">

其他：
　　 undo 是在事務開始之前保存的被修改數據的一個版本，產生 undo 日志的時候，同樣會伴隨類似于保護事務持久化機制的 redolog 的產生。
　　默認情況下 undo 文件是保持在共享表空間的，也即 ibdatafile 文件中，當數據庫中發生一些大的事務性操作的時候，要生成大量的 undo 信息，全部保存在共享表空間中的。
　　因此共享表空間可能會變的很大，默認情況下，也就是 undo 日志使用共享表空間的時候，被 “ 撐大 ” 的共享表空間是不會也不能自動收縮的。
　　因此， mysql5.7 之后的 “ 獨立 undo 表空間 ” 的配置就顯得很有必要了。

二進制日志（ binlog ）：

作用：
　　 1 ，用于復制，在主從復制中，從庫利用主庫上的 binlog 進行重播，實現主從同步。
　　 2 ，用于數據庫的基于時間點的還原。
內容：
　　邏輯格式的日志，可以簡單認為就是執行過的事務中的 sql 語句。
　　但又不完全是 sql 語句這么簡單，而是包括了執行的 sql 語句（增刪改）反向的信息，
　　也就意味著 delete 對應著 delete 本身和其反向的 insert ； update 對應著 update 執行前后的版本的信息； insert 對應著 delete 和 insert 本身的信息。
　　在使用 mysqlbinlog 解析 binlog 之后一些都會 真相大白 。
　　因此可以基于 binlog 做到類似于 oracle 的閃回功能，其實都是依賴于 binlog 中的日志記錄。

什么時候產生：
　　事務提交的時候，一次性將事務中的 sql 語句（一個事物可能對應多個 sql 語句）按照一定的格式記錄到 binlog 中。
　　這里與 redo log 很明顯的差異就是 redo log 并不一定是在事務提交的時候刷新到磁盤， redo log 是在事務開始之后就開始逐步寫入磁盤。
　　因此對于事務的提交，即便是較大的事務，提交（ commit ）都是很快的，但是在開啟了 bin_log 的情況下，對于較大事務的提交，可能會變得比較慢一些。
　　這是因為 binlog 是在事務提交的時候一次性寫入的造成的，這些可以通過測試驗證。

什么時候釋放：
　　 binlog 的默認是保持時間由參數 expire_logs_days 配置，也就是說對于非活動的日志文件，在生成時間超過 expire_logs_days 配置的天數之后，會被自動刪除。
　　

對應的物理文件：
　　配置文件的路徑為 log_bin_basename ， binlog 日志文件按照指定大小，當日志文件達到指定的最大的大小之后，進行滾動更新，生成新的日志文件。
　　對于每個 binlog 日志文件，通過一個統一的 index 文件來組織。

cDNLxlIf//vy0J+PsP2zB/af8ObTBideU79I1EvX4cayr3hDmoKDMRZwoIIdbUO4MJbwY2PyvvQwSdkvspMLis1iHCznJ0vmIiO9sW314UHFMtJ1eRrzy8Jl3+fsfrL9Ct6rSpbsZQNfYl6+KLO0ov958SGKzuOXx9eMr2AocrvAv+xtFBMRv5MACZDAXQgUbjrLbPy654126i7Y6CEb9owNWOQUcuKfdRXEC4/pow2tPGYYK22Kgdsuid/lkuQHK90ssO5nbzH84PHWGdrAxrS/jld06nRhGxIgARJoA4G/JMP+9etXG2yljSRAAiRAAiTQWQLMsDvreg6cBEiABEigTQQ4YbfJW7SVBEiABEigswQ4YXfW9Rw4CZAACZBAmwhwwm6Tt2grCZAACZBAZwlwwu6s6zlwEiABEiCBNhH4H0G/jmQnBPsTAAAAAElFTkSuQmCC"> 　

其他：
　　二進制日志的作用之一是還原數據庫的，這與 redo log 很類似，很多人混淆過，但是兩者有本質的不同
　　 1 ，作用不同： redo log 是保證事務的持久性的，是事務層面的， binlog 作為還原的功能，是數據庫層面的 （當然也可以精確到事務層面的），雖然都有還原的意思，但是其保護數據的層次是不一樣的。
　　 2 ，內容不同： redo log 是物理日志，是數據頁面的修改之后的物理記錄 ， binlog 是邏輯日志，可以簡單認為記錄的就是 sql 語句
　　 3 ，另外，兩者日志產生的時間，可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。
　　 4 ，恢復數據時候的效率，基于物理日志的 redo log 恢復數據的效率要高于語句邏輯日志的 binlog

　　關于事務提交時， redo log 和 binlog 的寫入順序，為了保證主從復制時候的主從一致（當然也包括使用 binlog 進行基于時間點還原的情況），是要嚴格一致的，
　　 MySQL 通過兩階段提交過程來完成事務的一致性的，也即 redo log 和 binlog 的一致性的，理論上是先寫 redo log ，再寫 binlog ，兩個日志都提交成功（刷入磁盤），事務才算真正的完成。
　　參考： http://www.cnblogs.com/hustcat/p/3577584.html

總結：

　　 MySQL 中，對于以上三種日志，每一種細化起來都可以夠寫一個章節的，這里粗略地總結了一下三種日志的一些特點和作用，以幫助理解 MySQL 中的事物以及事物背后的原理。

Mysql 重做日志及與二進制日志的區別

Mysql 重做日志及與二進制日志的區別 （轉 http://blog.uouo123.com/post/623.html ）

Mysql 默認情況下會有兩個文件： ib_logfile0 和 ib_logfile1 ，這兩個文件就是重做日志文件，或者事務日志 。

重做日志的目的： 萬一實例或者介質失敗，重做日志文件就能派上用場 。

每個 InnoDB 存儲引擎至少有一個重做日志文件組，每個文件組下至少有 2 個重做日志文件，如默認的 ib_logfile0 、 ib_logfile1 。 InnoDB 存儲引擎先寫重做日志文件 1 ，當達到文件的最后時，會切換至重做日志文件 2 ，當重做日志文件 2 也被寫滿時，會再被切換到重做日志文件 1 中 。

影響重做日志的參數 ：

Innodb_log_file_size 、 innodb_log_files_in_group 、 innodb_log_group_home_dir 影響著重做日志文件的屬性 。

  VPSVjlZsvFbD8jU3AruPU5S8Gt4LZKJDupX1U24qEA0Mu+22eTabD1lffBHDNWnZTJtJ9Z79h+snWx5XzzE6rbzHgUyRTcCm4bjaLG3okzhie4Fdz6HK/gVnAruG32iZY+m+wkaMYMwLD9ZGCOWe8Et+2aE3PMfGOrtIQeBOrYhudTElYhmXKCW8Gtb4ER3ApuBbeC204Cdew11lcfs3bGjrayMn3+mtl8KHLbg6DJTGyIEjUJmorc1guaMXWjSIdCHQerj90kM704+BaLkIUg3c8qYFV2bJuQmV6kBoNMpSX8r+0x8XnjEQIwsdaobpYZ078w/SzrN6rMJyuTab9PJ0LXqBgyFbntQaCObXg+xWSNgCmnyG29QB1TNwS39d2A1AmgFtzWN59NbWTT/jOW7w6BicEgM6YfZcaWWTtDNuwxZTJ1+XRCcNuDoBnTqcWsizWWpmUKbgW3PmeptITpVsnaMFtOcCu4rRLpS64VZWw4S/8YiIy5Rvna7YO0MleQGJmsDbPlYspk6vKNm+BWcNuy44F6OU1wK7j1OUvBreA2b7FkYciVG6h+dDCBpuA2fFPm87Ehm2emLsHtjGhEGYr3DV5saGINii3HOmWmn0xdITu8JmXGnif20nnMeepmmTF1g+1nEzLLRExYG+hEikAnZCpyGw4JrA415V/S/jOW7w4BmMEgM6ZPY8aW1TO2XEyZTF0+nSjDfMwcFLVNObc9GC1mJj3ECHyKydbFlBPcKnLrc5aK3Cpyq8itTktIR6fL+I2sDR27fsZaF33tDomiMmss0+4QmUz7fTIFtz0ImjF37DHrCjECn2KydTHlBLeCW5+zFNwKbgW3glvBbZ8fqAMOmfWaYQOGW+pov69titz2IFCzO0+mHKOYrBEw5QS3glvBbf+bxarAHGN3WfUPBplFPpDxjyFj61ts2brYcjF9t88mOwmanehnbN3w1cfOOVuOmc+Ydfl0X3Dbg6AZ2/B8SsIqJFsuZvsZmYJbwa3P8Spyq8htFfBO6pfgVufchqw5zPpbB6gxa6fTax8os31gZfr8NcMQdYyZr5//HzsjGEING1yUAAAAAElFTkSuQmCC">

重做日志與二進制日志的區別 ：

1 ）二進制日志會記錄所有與 mysql 有關的日志記錄，包括 InnoDB 等其他存儲引擎的日志，而 InnoDB 存儲引擎的重做日志只記錄有關其本身的事務日志 ，

2 ）記錄的內容不容，不管你將二進制日志文件記錄的格式設為哪一種， 其記錄的都是關于一個事務的具體操作內容，而 InnoDB 存儲引擎的重做日志文件記錄的關于每個頁的更改的物理情況 ；

3 ）寫入的時間也不同，二進制日志文件是在事務提交前進行記錄的，而在事務進行的過程中，不斷有重做日志條目被寫入重做日志文件中 。

從日志緩沖寫入磁盤上的重做日志文件的條件 ：

在主線程中每秒會將重做日志緩沖寫入磁盤的重做日志文件中，不論事務是否提交。另一個觸發這個過程是由參數 innodb_flush_log_at_trx_commit 控制，表示在提交時，處理重做日志的方式 。

參數 innodb_flush_log_at_trx_commit 可設的值有 、 1 、 2,0 代表當提交事務時，并不將事務的重做日志寫入磁盤上的日志文件，而是等待主線程每秒的刷新，而 1 和 2 不同的地方在于： 1 是在 commit 時將重做日志緩沖同步寫到磁盤； 2 是重做日志異步寫到磁盤，即不能完全保證 commit 時肯定會寫入重做日志文件，只是有這個動作 。

  值得注意的一點：因為重做日志有個 capacity 變量，該值代表了最后的檢查點不能超過這個閥值 。