怎么把mysql表里的时间往后推移_Mysql实战45讲笔记:2、更新语句的执行以及日志...
執行語句前要先連接數據庫,這是連接器的工作。
前面我們說過,在一個表上有更新的時候,跟這個表有關的查詢緩存會失效,所以這條語句就會把表T上所有緩存結果都清空。這也就是我們一般不建議使用查詢緩存的原因。
接下來,分析器會通過詞法和語法解析知道這是一條更新語句。優化器決定要使用ID這個索引。然后,執行器負責具體執行,找到這一行,然后更新。
與查詢流程不一樣的是,更新流程還涉及兩個重要的日志模塊,它們正是我們今天要討論的主角:redo log(重做日志)和 binlog(歸檔日志)。
重要的日志模塊:redo log
當有一條記錄需要更新的時候,InnoDB引擎就會先把記錄寫到redo log(粉板)里面,并更新內存,這個時候更新就算完成了。同時,InnoDB引擎會在適當的時候,將這個操作記錄更新到磁盤里面,而這個更新往往是在系統比較空閑的時候做。 InnoDB的redo log是固定大小的,比如可以配置為一組4個文件,每個文件的大小是1GB,那么總共就可以記錄4GB的操作。從頭開始寫,寫到末尾就又回到開頭循環寫,如下面這個圖所示。
write pos是當前記錄的位置,一邊寫一邊后移,寫到第3號文件末尾后就回到0號文件開頭。checkpoint是當前要擦除的位置,也是往后推移并且循環的,擦除記錄前要把記錄更新到數據文件。
write pos和checkpoint之間的是還空著的部分,可以用來記錄新的操作。如果write pos追上checkpoint,表示滿了,這時候不能再執行新的更新,得停下來先擦掉一些記錄,把checkpoint推進一下。
有了redo log,InnoDB就可以保證即使數據庫發生異常重啟,之前提交的記錄都不會丟失,這個能力稱為crash-safe。
重要的日志模塊:binlog
MySQL整體來看,其實就有兩塊:一塊是Server層,它主要做的是MySQL功能層面的事情;還有一塊是引擎層,負責存儲相關的具體事宜。上面我們聊到的redo log是InnoDB引擎特有的日志,而Server層也有自己的日志,稱為binlog(歸檔日志)。
最開始MySQL里并沒有InnoDB引擎。MySQL自帶的引擎是MyISAM,但是MyISAM沒有crash-safe的能力,binlog日志只能用于歸檔。而InnoDB是另一個公司以插件形式引入MySQL的,既然只依靠binlog是沒有crash-safe能力的,所以InnoDB使用另外一套日志系統——也就是redo log來實現crash-safe能力。
這兩種日志有以下三點不同:
有了對這兩個日志的概念性理解,我們再來看執行器和InnoDB引擎在執行這個簡單的update語句時的內部流程:
圖中淺色框表示是在InnoDB內部執行的,深色框表示是在執行器中執行的。
最后三步看上去有點“繞”,將redo log的寫入拆成了兩個步驟:prepare和commit,這就是"兩階段提交"
tip
- redo log用于保證crash-safe能力。innodb_flush_log_at_trx_commit這個參數設置成1的時候,表示每次事務的redo log都直接持久化到磁盤。這個參數建議設置成1,這樣可以保證MySQL異常重啟之后數據不丟失。
- sync_binlog這個參數設置成1的時候,表示每次事務的binlog都持久化到磁盤。這個參數建議設置成1,這樣可以保證MySQL異常重啟之后binlog不丟失。
總結
以上是生活随笔為你收集整理的怎么把mysql表里的时间往后推移_Mysql实战45讲笔记:2、更新语句的执行以及日志...的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 涉嫌滥用应用市场主导地位,意大利反垄断机
- 下一篇: linux cmake编译源码,linu