MySQL執行流程

MySQL執行流程

select陳述句執行流程

增刪改陳述句執行流程

update陳述句的整體執行流程和select陳述句是一樣的，只是少了快取的那一步驟，

mysql想完成資料的修改，會先從存盤引擎層讀取資料，把資料讀取到服務層進行資料的修改，再通過存盤引擎層把資料更新到資料庫中，

mysql每次讀取資料都會讀取16384B的資料，默認是16KB的資料，一頁的資料，

在innodb引擎中設計了 buffer pool 緩沖區，Mysql從磁盤中通過IO讀取資料到buffer pool中，引擎從bffer pool中獲取資料，然后修改，再把資料寫入到buffer pool中，從而完成讀寫的操作，因為是基于記憶體的操作，所以速度是非常快的，

臟資料：buffer pool中的資料，還沒有同步到磁盤中的資料稱為臟資料，

innodb的臟頁重繪機制說明：

1、當innodb中的臟頁比例超過innodb_max_dirty_pages_pct_lwm的值時，這個時候innodb就會開始重繪臟頁到磁盤，

2、當innodb中的臟頁比例超過innodb_max_dirty_pages_pct_lwm的值，而且還超過innodb_max_dirty_pages_pct時innodb就會進入勤快重繪模式(agressively flush）這個模式下innodb會把臟頁更快的重繪到磁盤，

3、還有一種情況叫做sharp checkpoint ,當innodb要重用它之前的redo檔案時，就會把innodb_buffer_pool中所有與這個檔案有關的頁面都要重繪到磁盤；這樣做就有可能引起磁盤的IO風暴了，輕者影響性能，重者影響可用性，

對于控制重繪機制的各個引數的說明：

1、innodb_max_dirty_pages_pct默認值為75，也就是說當臟頁比例超過75%時才會進入勤快重繪模式，

2、innodb_max_dirty_pages_pct_lwm默認值是0，0對于innodb_max_dirty_pages_pct_lwm來說是一個特殊值，它表示不啟用這個功能；由于沒有啟用這個功能，也就是說innodb_buffer_pool中的臟頁比例會操持在75%左右，

Mysql會在后臺使用若干執行緒，負責把buffer pool中的資料重繪到磁盤中去，

后臺常用的執行緒：

master thread 主執行緒

IO thread IO操作的執行緒

Purge thread 清理資料和日志的執行緒

Page C1eaner thred 刷臟的執行緒

查看buffer pool的大小，默認是128M

# 查詢innodb buffer pool相關配置
show VARIABLES like '%innodb_buffer_pool%';

資料存盤到buffer pool中，默認是128M，如果buffer pool存滿了，那么innodb引擎會使用改良的LRU演算法清理資料，

注意：LRU演算法是最近最久未使用法，mysql會對LRU的演算法進行改良，

官網檔案地址：https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html

冷熱分離的方式:

新的資料剛進來的時候進入冷區域，如果下一秒被呼叫就進去熱區域頂部，熱區域的資料都會向下移動，

redo log 日志

redo log日志是innodb存盤引擎自帶的，

避免服務器宕機或者其他突發事件，導致需要保存到資料庫的資料還沒來得及存盤，所以才有了redo log，在mysql事務的層面上來說，redo log保證了資料的持久性，

問題：資料沒有直接存入到磁盤上，而是先存入到buffer pool中，然后再刷入磁盤，目的是為了性能考慮，但是現在有需要存入到redo log 日志的磁盤檔案中，這樣性能不就下降了？

答案：性能肯定是會有一些影響，但是需要保證資料可恢復的能力，寫入redo log磁盤檔案中的速度會更快一些，

隨機磁盤IO和順序磁盤IO的區別，

隨機磁盤IO的情況是資料是會分散到不同的扇區去存盤，因為底層是通過索引的順序來存盤，索引會存盤到不同的扇區，那么更新資料的時候會增加尋道的時間，寫入資料會變慢，

順序磁盤IO是按著順序追加寫入的， 速度會快一些，

# 通過命令查看innodb_log相關的資訊，
show VARIABLES like '%innodb_log%';

默認是分成2組innodb_log_files_in_group，所以產生2個日志檔案，

每個檔案的大小默認是48Minnodb_log_file_size 固定的（可以修改），資料滿了會產生覆寫的效果，

站在mysql事務的角度，redo log日志是事務持久性的保證，

log buffer 刷盤機制(什么時候將記錄的資料存盤到磁盤中)，官網說明

log buffer刷盤時間間隔

每隔一秒刷盤一次，但是具體的刷盤策略由innodb_flush_log_at_trx_commit引數來決定，

log buffer 刷盤機制:

innodb_flush_log_at_trx_commit：用來控制redo log重繪到磁盤的策略，

當設定為1的時候，事務每次提交都會將log buffer中的日志寫入os buffer并呼叫fsync()刷到log file on disk中，這種方式即使系統崩潰也不會丟失任何資料，但是因為每次提交都寫入磁盤，IO的性能較差，

當設定為0的時候，事務提交時不會將log buffer中日志寫入到os buffer，而是每秒寫入os buffer并呼叫fsync()寫入到log file on disk中，也就是說設定為0時是(大約)每秒重繪寫入到磁盤中的，當系統崩潰，會丟失1秒鐘的資料，

當設定為2的時候，每次提交都僅寫入到os buffer，然后是每秒呼叫fsync()將os buffer中的日志寫入到log file on disk，

undo log日志

undo log日志是innodb存盤引擎自帶的，

undo log可以稱為撤銷日志或者回滾日志，站在事務的角度，undo log可以保證事務的原子性，

日志中記錄的反向操作，例如：把username=”張三” 修改成了username=”趙四”，那么undo log中記錄的是原來的值，即 username=”張三” 這樣資料庫再發生回滾操作的時候，可以把資料恢復回來，

本地存盤位置：

show VARIABLES like '%undo%';

bin log 日志

bin log是mysql服務端的日志，

binary log 二進制日志，屬于mysql服務層的日志，bin log是默認關閉的，

binlog是記錄所有資料庫表結構變更（例如CREATE、ALTER TABLE…）以及表資料修改（INSERT、UPDATE、DELETE…）的二進制日志，

binlog不會記錄SELECT和SHOW這類操作，因為這類操作對資料本身并沒有修改，但你可以通過查詢通用日志來查看MySQL執行過的所有陳述句，

主要作用是主從復制和資料恢復的作用，

特點：

記錄DDL和DML的陳述句，屬于邏輯日志

沒有固定大小限制，內容可以追加

Server層實作，可以被所有存盤引擎使用

用于資料恢復和主從復制，

show GLOBAL VARIABLES like '%log_bin%';

bin log主從復制的原理流程圖:

總結

標籤：MySQL

上一篇：DataX插件二次開發指南

下一篇：MySQL插入資料的多種方式