技術文章 » 圖文詳解mysql架構原理

圖文詳解mysql架構原理

2022-05-17 19:00:19
本篇文章給大家帶來了關於的相關知識，其中主要介紹了關於架構原理的相關內容，MySQL Server架構自頂向下大致可以分網路連線層、服務層、儲存引擎層和系統檔案層，下面一起來看一下，希望對大家有幫助。

推薦學習：

Mysql 架構原理

1、Mysql體系架構

MySQL Server架構自頂向下大致可以分網路連線層、服務層、儲存引擎層和系統檔案層。

image-20220515204322843

網路連線層

  • 使用者端聯結器（Client Connectors）：提供與MySQL伺服器建立的支援。目前幾乎支援所有主流的伺服器端程式設計技術，例如常見的 Java、C、Python、.NET等，它們通過各自API技術與MySQL建立連線。

服務層（MySQL Server）

服務層是MySQL Server的核心，主要包含系統管理和控制工具、連線池、SQL介面、解析器、查詢優化器和快取六個部分。

  • 連線池（Connection Pool）：負責儲存和管理使用者端與資料庫的連線，一個執行緒負責管理一個連線。

  • 系統管理和控制工具（Management Services & Utilities）：例如備份恢復、安全管理、叢集管理等

  • SQL介面（SQL Interface）：用於接受使用者端傳送的各種SQL命令，並且返回使用者需要查詢的結果。比如DML、DDL、儲存過程、檢視、觸發器等。

  • 解析器（Parser）：負責將請求的SQL解析生成一個"解析樹"。然後根據一些MySQL規則進一步檢查解析樹是否合法。

  • 查詢優化器（Optimizer）：當"解析樹"通過解析器語法檢查後，將交由優化器將其轉化成執行計劃，然後與儲存引擎互動。

    select uid, name from user where gender = 1;

    選取 --》投影 --》聯接 策略

    1. select先根據where語句進行選取，並不是查詢出全部資料再過濾；
    2. select查詢根據uid和name進行屬性投影，並不是取出所有欄位；
    3. 將前面選取和投影聯接起來最終生成查詢結果；

  • 快取（Cache&Buffer）： 快取機制是由一系列小快取組成的。比如錶快取，記錄快取，許可權快取，引擎快取等。如果查詢快取有命中的查詢結果，查詢語句就可以直接去查詢快取中取資料。

儲存引擎層（Pluggable Storage Engines）

  • 儲存引擎負責MySQL中資料的儲存與提取，與底層系統檔案進行互動。MySQL儲存引擎是外掛式的，伺服器中的查詢執行引擎通過介面與儲存引擎進行通訊，介面遮蔽了不同儲存引擎之間的差異 。現在有很多種儲存引擎，各有各的特點，最常見的是MyISAM和InnoDB。

系統檔案層（File System）

該層負責將資料庫的資料和紀錄檔儲存在檔案系統之上，並完成與儲存引擎的互動，是檔案的物理儲存層。主要包含紀錄檔檔案，資料檔案，組態檔，pid 檔案，socket 檔案等。

  • 紀錄檔檔案
    • 錯誤紀錄檔（Error log）
      • 預設開啟，show variables like ‘%log_error%’;
    • 通用查詢紀錄檔（General query log）
      • 記錄一般查詢語句，show variables like ‘%general%’;
    • 二進位制紀錄檔（binary log）
      • 記錄了對MySQL資料庫執行的更改操作，並且記錄了語句的發生時間、執行時長；但是它不記錄select、show等不修改資料庫的SQL。主要用於資料庫恢復和主從複製。
      • show variables like ‘%log_bin%’; //是否開啟
      • show variables like ‘%binlog%’; //引數檢視
      • show binary logs;//檢視紀錄檔檔案
    • 慢查詢紀錄檔（Slow query log）
      • 記錄所有執行時間超時的查詢SQL，預設是10秒。
      • show variables like ‘%slow_query%’; //是否開啟
      • show variables like ‘%long_query_time%’; //時長
  • 組態檔
    • 用於存放MySQL所有的設定資訊檔案，比如my.cnf、my.ini等。
  • 資料檔案
    • db.opt 檔案：記錄這個庫的預設使用的字元集和校驗規則。
    • frm 檔案：儲存與表相關的後設資料（meta）資訊，包括表結構的定義資訊等，每一張表都會有一個frm 檔案。
    • MYD 檔案：MyISAM 儲存引擎專用，存放 MyISAM 表的資料（data)，每一張表都會有一個.MYD 檔案。
    • MYI 檔案：MyISAM 儲存引擎專用，存放 MyISAM 表的索引相關資訊，每一張 MyISAM 表對應一個 .MYI檔案。
    • ibd檔案和 IBDATA 檔案：存放 InnoDB 的資料檔案（包括索引）。InnoDB 儲存引擎有兩種表空間方式：獨享表空間和共用表空間。獨享表空間使用 .ibd 檔案來存放資料，且每一張InnoDB 表對應一個 .ibd 檔案。共用表空間使用 .ibdata 檔案，所有表共同使用一個（或多個，自行設定）.ibdata 檔案。
    • ibdata1 檔案：系統表空間資料檔案，儲存表後設資料、Undo紀錄檔等 。
    • ib_logfile0、ib_logfile1 檔案：Redo log 紀錄檔檔案。
  • pid 檔案
    • pid 檔案是 mysqld 應用程式在 Unix/Linux 環境下的一個程序檔案，和許多其他 Unix/Linux 伺服器端程式一樣，它存放著自己的程序 id。
  • socket 檔案
    • socket 檔案也是在 Unix/Linux 環境下才有的，使用者在 Unix/Linux 環境下使用者端連線可以不通過TCP/IP 網路而直接使用 Unix Socket 來連線 MySQL。

2、MySQL執行機制

image-20220515211108275

  1. 建立連線（Connectors&Connection Pool），通過使用者端/伺服器通訊協定與MySQL建立連線。MySQL 使用者端與伺服器端的通訊方式是 「 半雙工 」。對於每一個 MySQL 的連線，時刻都有一個執行緒狀態來標識這個連線正在做什麼。
    • 通訊機制：
      • 全雙工：能同時傳送和接收資料，例如平時打電話。
      • 半雙工：指的某一時刻，要麼傳送資料，要麼接收資料，不能同時。例如早期對講機
      • 單工：只能傳送資料或只能接收資料。例如單行道；
    • 執行緒狀態：show processlist; //檢視使用者正在執行的執行緒資訊，root使用者能檢視所有執行緒，其他使用者只能看自己的；
      • id：執行緒ID，可以使用kill xx；
      • user：啟動這個執行緒的使用者
      • Host：傳送請求的使用者端的IP和埠號
      • db：當前命令在哪個庫執行
      • Command：該執行緒正在執行的操作命令
        • Create DB：正在建立庫操作
        • Drop DB：正在刪除庫操作
        • Execute：正在執行一個PreparedStatement
        • Close Stmt：正在關閉一個PreparedStatement
        • Query：正在執行一個語句
        • Sleep：正在等待使用者端傳送語句
        • Quit：正在退出
        • Shutdown：正在關閉伺服器
      • Time：表示該執行緒處於當前狀態的時間，單位是秒
      • State：執行緒狀態
        • Updating：正在搜尋匹配記錄，進行修改
        • Sleeping：正在等待使用者端傳送新請求
        • Starting：正在執行請求處理
        • Checking table：正在檢查資料表
        • Closing table : 正在將表中資料重新整理到磁碟中
        • Locked：被其他查詢鎖住了記錄
        • Sending Data：正在處理Select查詢，同時將結果傳送給使用者端
      • Info：一般記錄執行緒執行的語句，預設顯示前100個字元。想檢視完整的使用show full processlist;
  2. 查詢快取（Cache&Buffer），這是MySQL的一個可優化查詢的地方，如果開啟了查詢快取且在查詢快取過程中查詢到完全相同的SQL語句，則將查詢結果直接返回給使用者端；如果沒有開啟查詢快取或者沒有查詢到完全相同的 SQL 語句則會由解析器進行語法語意解析，並生成「解析樹」。
    • 快取Select查詢的結果和SQL語句；
    • 執行Select查詢時，先查詢快取，判斷是否存在可用的記錄集，要求是否完全相同（包括引數值），這樣才會匹配快取資料命中；
    • 即使開啟查詢快取，以下SQL也不能快取：
      • 查詢語句使用SQL_NO_CACHE
      • 查詢的結果大於query_cache_limit設定
      • 查詢中有一些不確定的引數，比如now()
    • show variables like ‘%query_cache%’; //檢視查詢快取是否啟用，空間大小，限制等
    • show status like ‘Qcache%’; //檢視更詳細的快取引數，可用快取空間，快取塊，快取多少等
  3. 解析器（Parser）將使用者端傳送的SQL進行語法解析，生成"解析樹"。前處理器根據一些MySQL規則進一步檢查「解析樹」是否合法，例如這裡將檢查資料表和資料列是否存在，還會解析名字和別名，看看它們是否有歧義，最後生成新的「解析樹」。
  4. 查詢優化器（Optimizer）根據「解析樹」生成最優的執行計劃。MySQL使用很多優化策略生成最優的執行計劃，可以分為兩類：靜態優化（編譯時優化）、動態優化（執行時優化）。
    • 等價變換策略
      • 5=5 and a>5 改成 a > 5
      • a < b and a=5 改成b>5 and a=5
      • 基於聯合索引，調整條件位置等
    • 優化count、min、max等函數
      • InnoDB引擎min函數只需要找索引最左邊
      • InnoDB引擎max函數只需要找索引最右邊
      • MyISAM引擎count(*)，不需要計算，直接返回
    • 提前終止查詢
      • 使用了limit查詢，獲取limit所需的資料，就不在繼續遍歷後面資料
    • in的優化
      • MySQL對 in 查詢，會先進行排序，再採用二分法查詢資料。比如where id in (2,1,3)，變成 in (1,2,3)；
  5. 查詢執行引擎負責執行 SQL 語句，此時查詢執行引擎會根據 SQL 語句中表的儲存引擎型別，以及對應的API介面與底層儲存引擎快取或者物理檔案的互動，得到查詢結果並返回給使用者端。若開啟用查詢快取，這時會將SQL 語句和結果完整地儲存到查詢快取（Cache&Buffffer）中，以後若有相同的 SQL 語句執行則直接返回結果。
    • 如果開啟了查詢快取，先將查詢結果做快取操作
    • 返回結果過多，採用增量模式返回
    • 開始執行的時候，要先判斷一下你對這個表 T 有沒有執行查詢的許可權，如果沒有，就會返回沒有許可權的錯誤，（如果命中查詢快取，會在查詢快取返回結果的時候，做許可權驗證。查詢也會在優化器之前呼叫 precheck 驗證許可權）。
    • 如果有許可權，就開啟表繼續執行。開啟表的時候，執行器就會根據表的引擎定義，去使用這個引擎提供的介面。執行器的執行流程是這樣的：
      • select * from test where age > 10;
      • 呼叫 InnoDB 引擎介面取這個表的第一行，判斷 age 值是不是 10，如果不是則跳過，如果是則將這行存在結果集中；
      • 呼叫引擎介面取「下一行」，重複相同的判斷邏輯，直到取到這個表的最後一行。
      • 執行器將上述遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給使用者端。

3、Mysql儲存引擎

儲存引擎在MySQL的體系架構中位於第三層，負責MySQL中的資料的儲存和提取，是與檔案打交道的子系統，它是根據MySQL提供的檔案存取層抽象介面客製化的一種檔案存取機制，這種機制就叫作儲存引擎。

使用show engines命令，就可以檢視當前資料庫支援的引擎資訊。image-20220515211931975

在5.5版本之前預設採用MyISAM儲存引擎，從5.5開始採用InnoDB儲存引擎。

  • InnoDB：支援事務，具有提交，回滾和崩潰恢復能力，事務安全；
  • MyISAM：不支援事務和外來鍵，存取速度快；
  • Memory：利用記憶體建立表，存取速度非常快，因為資料在記憶體，而且預設使用Hash索引，但是一旦關閉，資料就會丟失；
  • Archive：歸檔型別引擎，僅能支援insert和select語句；
  • Csv：以CSV檔案進行資料儲存，由於檔案限制，所有列必須強制指定not null，另外CSV引擎也不支援索引和分割區，適合做資料交換的中間表；
  • BlackHole: 黑洞，只進不出，進來消失，所有插入資料都不會儲存；
  • Federated：可以存取遠端MySQL資料庫中的表。一個本地表，不儲存資料，存取遠端表內容。
  • MRG_MyISAM：一組MyISAM表的組合，這些MyISAM表必須結構相同，Merge表本身沒有資料，對Merge操作可以對一組MyISAM表進行操作；

InnoDB和MyISAM對比

  • 事務和外來鍵
    • InnoDB支援事務和外來鍵，具有安全性和完整性，適合大量insert或update操作
    • MyISAM不支援事務和外來鍵，它提供高速儲存和檢索，適合大量的select查詢操作
  • 鎖機制
    • InnoDB支援行級鎖，鎖定指定記錄。基於索引來加鎖實現。
    • MyISAM支援表級鎖，鎖定整張表。
  • 索引結構
    • InnoDB使用聚集索引（聚簇索引），索引和記錄在一起儲存，既快取索引，也快取記錄。
    • MyISAM使用非聚集索引（非聚簇索引），索引和記錄分開。
  • 並行處理能力
    • MyISAM使用表鎖，會導致寫操作並行率低，讀之間並不阻塞，讀寫阻塞。
    • InnoDB讀寫阻塞可以與隔離級別有關，可以採用多版本並行控制（MVCC）來支援高並行
  • 儲存檔案
    • InnoDB表對應兩個檔案，一個.frm表結構檔案，一個.ibd資料檔案。InnoDB表最大支援64TB；
    • MyISAM表對應三個檔案，一個.frm表結構檔案，一個MYD表資料檔案，一個.MYI索引檔案。從
      MySQL5.0開始預設限制是256TB。
  • 適用場景
    • MyISAM
      • 不需要事務支援（不支援）
      • 並行相對較低（鎖定機制問題）
      • 資料修改相對較少，以讀為主
      • 資料一致性要求不高
    • InnoDB
      • 需要事務支援（具有較好的事務特性）
      • 行級鎖定對高並行有很好的適應能力
      • 資料更新較為頻繁的場景
      • 資料一致性要求較高
      • 硬體裝置記憶體較大，可以利用InnoDB較好的快取能力來提高記憶體利用率，減少磁碟IO
  • 總結
    • 兩種引擎該如何選擇？
      • 是否需要事務？有，InnoDB
      • 是否存在並行修改？有，InnoDB
      • 是否追求快速查詢，且資料修改少？是，MyISAM
      • 在絕大多數情況下，推薦使用InnoDB

InnoDB儲存結構

從MySQL 5.5版本開始預設使用InnoDB作為引擎，它擅長處理事務，具有自動崩潰恢復的特性。下面是官方的InnoDB引擎架構圖，主要分為記憶體結構和磁碟結構兩大部分。

image-20220515212711508

InnoDB記憶體結構

記憶體結構主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大元件。

  • Buffer Pool：緩衝池，簡稱BP。BP以Page頁為單位，預設大小16K，BP的底層採用連結串列資料結構管理Page。在InnoDB存取表記錄和索引時會在Page頁中快取，以後使用可以減少磁碟IO操作，提升效率。
    • Page管理機制
      • Page根據狀態可以分為三種型別：
        1. free page ： 空閒page，未被使用
        2. clean page：被使用page，資料沒有被修改過
        3. dirty page：髒頁，被使用page，資料被修改過，頁中資料和磁碟的資料產生了不一致
      • 針對上述三種page型別，InnoDB通過三種連結串列結構來維護和管理：
        1. free list ：表示空閒緩衝區，管理free page
        2. flush list：表示需要重新整理到磁碟的緩衝區，管理dirty page，內部page按修改時間排序。髒頁即存在於flush連結串列，也在LRU連結串列中，但是兩種互不影響，LRU連結串列負責管理page的可用性和放，而flush連結串列負責管理髒頁的刷盤操作。
        3. lru list：表示正在使用的緩衝區，管理clean page和dirty page，緩衝區以midpoint為基點，前面連結串列稱為new列表區，存放經常存取的資料，佔63%；後面的連結串列稱為old列表區，存放使用較少資料，佔37%。
    • 改進型LRU演演算法維護
      • 普通LRU：末尾淘汰法，新資料從連結串列頭部加入，釋放空間時從末尾淘汰
      • 改性LRU：連結串列分為new和old兩個部分，加入元素時並不是從表頭插入，而是從中間midpoint位置插入，如果資料很快被存取，那麼page就會向new列表頭部移動，如果資料沒有被存取，會逐步向old尾部移動，等待淘汰。
      • 每當有新的page資料讀取到buffer pool時，InnoDb引擎會判斷是否有空閒頁，是否足夠，如果有就將free page從free list列表刪除，放入到LRU列表中。沒有空閒頁，就會根據LRU演演算法淘汰LRU連結串列預設的頁，將記憶體空間釋放分配給新的頁。
    • Buffer Pool設定引數
      • show variables like ‘%innodb_page_size%’; //檢視page頁大小
      • show variables like ‘%innodb_old%’; //檢視lru list中old列表引數
      • show variables like ‘%innodb_buffer%’; //檢視buffffer pool引數
      • 建議：將innodb_buffer_pool_size設定為總記憶體大小的60%-80%，innodb_buffer_pool_instances可以設定為多個，這樣可以避免快取爭奪。
  • Change Buffer：寫緩衝區，簡稱CB。在進行DML操作時，如果BP沒有其相應的Page資料，並不會立刻將磁碟頁載入到緩衝池，而是在CB記錄緩衝變更，等未來資料被讀取時，再將資料合併恢復到BP中。
    • ChangeBuffer佔用BufferPool空間，預設佔25%，最大允許佔50%，可以根據讀寫業務量來進行調整。引數innodb_change_buffer_max_size;
    • 當更新一條記錄時，該記錄在BufferPool存在，直接在BufferPool修改，一次記憶體操作。如果該記錄在BufferPool不存在（沒有命中），會直接在ChangeBuffer進行一次記憶體操作，不用再去磁碟查詢資料，避免一次磁碟IO。當下次查詢記錄時，會先進性磁碟讀取，然後再從ChangeBuffer中讀取資訊合併，最終載入BufferPool中。
    • 寫緩衝區，僅適用於非唯一普通索引頁
    • 如果在索引設定唯一性，在進行修改時，InnoDB必須要做唯一性校驗，因此必須查詢磁碟，做一次IO操作。會直接將記錄查詢到BufferPool中，然後在緩衝池修改，不會在ChangeBuffer操作。
  • Adaptive Hash Index：自適應雜湊索引，用於優化對BP資料的查詢。InnoDB儲存引擎會監控對錶索引的查詢，如果觀察到建立雜湊索引可以帶來速度的提升，則建立雜湊索引，所以稱之為自適應。InnoDB儲存引擎會自動根據存取的頻率和模式來為某些頁建立雜湊索引。
  • Log Buffer：紀錄檔緩衝區，用來儲存要寫入磁碟上log檔案（Redo/Undo）的資料，紀錄檔緩衝區的內容定期重新整理到磁碟log檔案中。紀錄檔緩衝區滿時會自動將其重新整理到磁碟，當遇到BLOB或多行更新的大事務操作時，增加紀錄檔緩衝區可以節省磁碟I/O。
    • LogBuffer主要是用於記錄InnoDB引擎紀錄檔，在DML操作時會產生Redo和Undo紀錄檔；
    • LogBuffer空間滿了，會自動寫入磁碟。可以通過將innodb_log_buffer_size引數調大，減少磁碟IO頻率；
    • innodb_flush_log_at_trx_commit引數控制紀錄檔重新整理行為，預設為1
      • 0 ： 每隔1秒寫紀錄檔檔案和刷盤操作（寫紀錄檔檔案LogBuffer --> OS cache，刷盤OScache --> 磁碟檔案），最多丟失1秒資料
      • 1：事務提交，立刻寫紀錄檔檔案和刷盤，資料不丟失，但是會頻繁IO操作
      • 2：事務提交，立刻寫紀錄檔檔案，每隔1秒鐘進行刷盤操作

InnoDB磁碟結構

InnoDB磁碟主要包含Tablespaces，InnoDB Data Dictionary，Doublewrite Buffer、Redo Log和Undo Logs。

  • 表空間（Tablespaces）：用於儲存表結構和資料。表空間又分為系統表空間、獨立表空間、通用表空間、臨時表空間、Undo表空間等多種型別；

    • 系統表空間（The System Tablespace）

      • 包含InnoDB資料字典，Doublewrite Buffer，Change Buffer，Undo Logs的儲存區域。系統表空間也預設包含任何使用者在系統表空間建立的表資料和索引資料。系統表空間是一個共用的表空間因為它是被多個表共用的。該空間的資料檔案通過引數innodb_data_file_path控制，預設值是ibdata1:12M:autoextend(檔名為ibdata1、12MB、自動擴充套件)。
      • CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //建立表空 間ts1 CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //將表新增到ts1 表空間

    • 獨立表空間（File-Per-Table Tablespaces）

      • 預設開啟，獨立表空間是一個單表表空間，該表建立於自己的資料檔案中，而非建立於系統表空間中。當innodb_file_per_table選項開啟時，表將被建立於表空間中。否則，innodb將被建立於系統表空間中。每個表檔案表空間由一個.ibd資料檔案代表，該檔案預設被建立於資料庫目錄中。表空間的表檔案支援動態（dynamic）和壓縮（commpressed）行格式。

    • 通用表空間（General Tablespaces）

      • 通用表空間為通過create tablespace語法建立的共用表空間。通用表空間可以建立於mysql資料目錄外的其他表空間，其可以容納多張表，且其支援所有的行格式。

    • 復原表空間（Undo Tablespaces）

      • 復原表空間由一個或多個包含Undo紀錄檔檔案組成。在MySQL 5.7版本之前Undo佔用的是System Tablespace共用區，從5.7開始將Undo從System Tablespace分離了出來。
      • InnoDB使用的undo表空間由innodb_undo_tablespaces設定選項控制，預設為0。引數值為0表示使用系統表空間ibdata1;大於0表示使用undo表空間undo_001、undo_002等。

    • 臨時表空間（Temporary Tablespaces）

      • 分為session temporary tablespaces 和global temporary tablespace兩種：
        1. session temporary tablespaces 儲存的是使用者建立的臨時表和磁碟內部的臨時表。
        2. global temporary tablespace儲存使用者臨時表的回滾段（rollback segments ）。mysql伺服器正常關閉或異常終止時，臨時表空間將被移除，每次啟動時會被重新建立。

  • 資料字典（InnoDB Data Dictionary）

    • InnoDB資料字典由內部系統表組成，這些表包含用於查詢表、索引和表欄位等物件的後設資料。後設資料物理上位於InnoDB系統表空間中。由於歷史原因，資料字典後設資料在一定程度上與InnoDB表後設資料檔案（.frm檔案）中儲存的資訊重疊。

  • 雙寫緩衝區（Doublewrite Buffer）

    • 位於系統表空間，是一個儲存區域。在BufferPage的page頁重新整理到磁碟真正的位置前，會先將資料存在Doublewrite 緩衝區。如果在page頁寫入過程中出現作業系統、儲存子系統或mysqld程序崩潰，InnoDB可以在崩潰恢復期間從Doublewrite 緩衝區中找到頁面的一個好備份。在大多數情況下，預設情況下啟用雙寫緩衝區，要禁用Doublewrite 緩衝區，可以將innodb_doublewrite設定為0。使用Doublewrite 緩衝區時建議將innodb_flush_method設定為O_DIRECT。
      • MySQL的innodb_flush_method這個引數控制著innodb資料檔案及redo log的開啟、刷寫模式。有三個值：fdatasync(預設)，O_DSYNC，O_DIRECT。設定O_DIRECT表示資料檔案寫入操作會通知作業系統不要快取資料，也不要用預讀，直接從InnodbBuffer寫到磁碟檔案。
      • 預設的fdatasync意思是先寫入作業系統快取，然後再呼叫fsync()函數去非同步刷資料檔案與redo log的快取資訊。

  • 重做紀錄檔（Redo Log）

    • 重做紀錄檔是一種基於磁碟的資料結構，用於在崩潰恢復期間更正不完整事務寫入的資料。MySQL以迴圈方式寫入重做紀錄檔檔案，記錄InnoDB中所有對Buffer Pool修改的紀錄檔。當出現範例故障（像斷電），導致資料未能更新到資料檔案，則資料庫重新啟動時須redo，重新把資料更新到資料檔案。讀寫事務在執行的過程中，都會不斷的產生redo log。預設情況下，重做紀錄檔在磁碟上由兩個名為ib_logfile0和ib_logfile1的檔案物理表示。

  • 復原紀錄檔（Undo Logs）

    • 撤消紀錄檔是在事務開始之前儲存的被修改資料的備份，用於例外情況時回滾事務。撤消紀錄檔屬於邏輯紀錄檔，根據每行記錄進行記錄。撤消紀錄檔存在於系統表空間、撤消表空間和臨時表空間中。

新版本結構演變

image-20220515214541979

  • MySQL 5.7 版本
    • 將 Undo紀錄檔表空間從共用表空間 ibdata 檔案中分離出來，可以在安裝 MySQL 時由使用者自行指定檔案大小和數量。
    • 增加了 temporary 臨時表空間，裡面儲存著臨時表或臨時查詢結果集的資料。
    • Buffer Pool 大小可以動態修改，無需重新啟動資料庫範例。
  • MySQL 8.0 版本
    • 將InnoDB表的資料字典和Undo都從共用表空間ibdata中徹底分離出來了，以前需要ibdata中資料字典與獨立表空間ibd檔案中資料字典一致才行，8.0版本就不需要了。
    • temporary 臨時表空間也可以設定多個物理檔案，而且均為 InnoDB 儲存引擎並能建立索引，這樣加快了處理的速度。
    • 使用者可以像 Oracle 資料庫那樣設定一些表空間，每個表空間對應多個物理檔案，每個表空間可以給多個表使用，但一個表只能儲存在一個表空間中。
    • 將Doublewrite Buffer從共用表空間ibdata中也分離出來了。

InnoDB執行緒模型

image-20220515214958395

  • IO Thread
    • 在InnoDB中使用了大量的AIO（Async IO）來做讀寫處理，這樣可以極大提高資料庫的效能。在
      InnoDB共有10個IO Thread，分別是4個write，4個read，1個insert buffer和 1個log thread。
      • read thread ： 負責讀取操作，將資料從磁碟載入到快取page頁。4個
      • write thread：負責寫操作，將快取髒頁重新整理到磁碟。4個
      • log thread：負責將紀錄檔緩衝區內容重新整理到磁碟。1個
      • insert buffer thread ：負責將寫緩衝內容重新整理到磁碟。1個
  • Purge Thread
    • 事務提交之後，其使用的undo紀錄檔將不再需要，因此需要Purge Thread回收已經分配的undo頁。
    • show variables like ‘%innodb_purge_threads%’;
  • Page Cleaner Thread
    • 作用是將髒資料重新整理到磁碟，髒資料刷盤後相應的redo log也就可以覆蓋，即可以同步資料，又能
      達到redo log迴圈使用的目的。會呼叫write thread執行緒處理。
    • show variables like ‘%innodb_page_cleaners%’;
  • Master Thread
    • Master thread是InnoDB的主執行緒，負責排程其他各執行緒，優先順序最高。作用是將緩衝池中的資料非同步重新整理到磁碟 ，保證資料的一致性。包含：髒頁的重新整理（page cleaner thread）、undo頁回收（purge thread）、redo紀錄檔重新整理（log thread）、合併寫緩衝等。內部有兩個主處理，分別是每隔1秒和10秒處理。
    • 每1秒的操作：
      • 重新整理紀錄檔緩衝區，刷到磁碟
      • 合併寫緩衝區資料，根據IO讀寫壓力來決定是否操作
      • 重新整理髒頁資料到磁碟，根據髒頁比例達到75%才操作（innodb_max_dirty_pages_pct，
        innodb_io_capacity）
    • 每10秒的操作：
      • 重新整理髒頁資料到磁碟
      • 合併寫緩衝區資料
      • 重新整理紀錄檔緩衝區
      • 刪除無用的undo頁

InnoDB資料檔案

InnoDB檔案儲存結構

image-20220515215453178

  • InnoDB資料檔案儲存結構

    • 分為 ibd資料檔案 --> Segment（段）–>Extent（區）–> Page（頁）–>Row（行）
      • Tablesapce表空間，用於儲存多個ibd資料檔案，用於儲存表的記錄和索引。一個檔案包含多個段。
      • Segment段，用於管理多個Extent，分為資料段（Leaf node segment）、索引段（Non-leaf node
        segment）、回滾段（Rollback segment）。一個表至少會有兩個segment，一個管理資料，一個管理索引。每多建立一個索引，會多兩個segment。
      • Extent區，一個區固定包含64個連續的頁，大小為1M。當表空間不足，需要分配新的頁資源，不會
        一頁一頁分，直接分配一個區。
      • Page頁，用於儲存多個Row行記錄，大小為16K。包含很多種頁型別，比如資料頁，undo頁，系統頁，事務資料頁，大的BLOB物件頁。
      • Row行，包含了記錄的欄位值，事務ID（Trx id）、捲動指標（Roll pointer）、欄位指標（Field
        pointers）等資訊。

    • Page是檔案最基本的單位，無論何種型別的page，都是由page header，page trailer和page body組成。如下圖所示

image-20220515215736916

  • InnoDB檔案儲存格式

    • 通過 SHOW TABLE STATUS 命令 檢視

      image-20220515215943028

      • 一般情況下，如果row_format為REDUNDANT、COMPACT，檔案格式為Antelope；如果row_format為DYNAMIC和COMPRESSED，檔案格式為Barracuda。

      • 通過 information_schema 檢視指定表的檔案格式

        • select * from information_schema.innodb_sys_tables;

  • File檔案格式（File-Format）

    • 在早期的InnoDB版本中，檔案格式只有一種，隨著InnoDB引擎的發展，出現了新檔案格式，用於支援新的功能。目前InnoDB只支援兩種檔案格式：Antelope 和 Barracuda。
      • Antelope: 先前未命名的，最原始的InnoDB檔案格式，它支援兩種行格式：COMPACT和REDUNDANT，MySQL 5.6及其以前版本預設格式為Antelope。
      • Barracuda: 新的檔案格式。它支援InnoDB的所有行格式，包括新的行格式：COMPRESSED和 DYNAMIC。
    • 通過innodb_file_format 設定引數可以設定InnoDB檔案格式，之前預設值為Antelope，5.7版本開始改為Barracuda。

  • Row行格式（Row_format）

image-20220515220208534

  • 表的行格式決定了它的行是如何物理儲存的，這反過來又會影響查詢和DML操作的效能。如果在單個page頁中容納更多行，查詢和索引查詢可以更快地工作，緩衝池中所需的記憶體更少，寫入更新時所需的I/O更少。

  • InnoDB儲存引擎支援四種行格式：REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。

  • DYNAMIC和COMPRESSED新格式引入的功能有：資料壓縮、增強型長列資料的頁外儲存和大索引字首。

  • 每個表的資料分成若干頁來儲存，每個頁中採用B樹結構儲存；

  • 如果某些欄位資訊過長，無法儲存在B樹節點中，這時候會被單獨分配空間，此時被稱為溢位頁，該欄位被稱為頁外列。

    • REDUNDANT 行格式
      • 使用REDUNDANT行格式，表會將變長列值的前768位元組儲存在B樹節點的索引記錄中，其餘
        的儲存在溢位頁上。對於大於等於786位元組的固定長度欄位InnoDB會轉換為變長欄位，以便
        能夠在頁外儲存。
    • COMPACT 行格式
      • 與REDUNDANT行格式相比，COMPACT行格式減少了約20%的行儲存空間，但代價是增加了
        某些操作的CPU使用量。如果系統負載是受快取命中率和磁碟速度限制，那麼COMPACT格式
        可能更快。如果系統負載受到CPU速度的限制，那麼COMPACT格式可能會慢一些。
    • DYNAMIC 行格式
      • 使用DYNAMIC行格式，InnoDB會將表中長可變長度的列值完全儲存在頁外，而索引記錄只包含指向溢位頁的20位元組指標。大於或等於768位元組的固定長度欄位編碼為可變長度欄位。DYNAMIC行格式支援大索引字首，最多可以為3072位元組，可通過innodb_large_prefix引數控制。
    • COMPRESSED 行格式
      • COMPRESSED行格式提供與DYNAMIC行格式相同的儲存特性和功能，但增加了對錶和索引
        資料壓縮的支援。

  • 在建立表和索引時，檔案格式都被用於每個InnoDB表資料檔案（其名稱與*.ibd匹配）。修改檔案格式的方法是重新建立表及其索引，最簡單方法是對要修改的每個表使用以下命令：

    • ALTER TABLE 表名 ROW_FORMAT=格式型別;

Undo Log

Undo Log介紹

  • Undo：意為復原或取消，以復原操作為目的，返回指定某個狀態的操作。

  • Undo Log：資料庫事務開始之前，會將要修改的記錄存放到 Undo 紀錄檔裡，當事務回滾時或者資料庫崩潰時，可以利用 Undo 紀錄檔，復原未提交事務對資料庫產生的影響。

  • Undo Log產生和銷燬：Undo Log在事務開始前產生；事務在提交時，並不會立刻刪除undo log，innodb會將該事務對應的undo log放入到刪除列表中，後面會通過後臺執行緒purge thread進行回收處理。Undo Log屬於邏輯紀錄檔，記錄一個變化過程。例如執行一個delete，undolog會記錄一個insert；執行一個update，undolog會記錄一個相反的update。

  • Undo Log儲存：undo log採用段的方式管理和記錄。在innodb資料檔案中包含一種rollback segment回滾段，內部包含1024個undo log segment。可以通過下面一組引數來控制Undo log儲存。

  • #相關引數命令

show variables like '%innodb_undo%';

Undo Log作用

  • 實現事務的原子性
    • Undo Log 是為了實現事務的原子性而出現的產物。事務處理過程中，如果出現了錯誤或者使用者執行了 ROLLBACK 語句，MySQL 可以利用 Undo Log 中的備份將資料恢復到事務開始之前的狀態。

  • 實現多版本並行控制（MVCC）

    • Undo Log 在 MySQL InnoDB 儲存引擎中用來實現多版本並行控制。事務未提交之前，Undo Log儲存了未提交之前的版本資料，Undo Log 中的資料可作為資料舊版本快照供其他並行事務進行快照讀。

image-20220515221157888

  • 事務A手動開啟事務，執行更新操作，首先會把更新命中的資料備份到 Undo Buffer 中；

  • 事務B手動開啟事務，執行查詢操作，會讀取 Undo 紀錄檔資料返回，進行快照讀；

  • Redo Log 和 Binlog

Redo Log 紀錄檔

  • Redo Log 介紹

    • Redo：顧名思義就是重做。以恢復操作為目的，在資料庫發生意外時重現操作。
    • Redo Log：指事務中修改的任何資料，將最新的資料備份儲存的位置（Redo Log），被稱為重做紀錄檔。
    • Redo Log 的生成和釋放：隨著事務操作的執行，就會生成Redo Log，在事務提交時會將產生Redo Log寫入Log Buffer，並不是隨著事務的提交就立刻寫入磁碟檔案。等事務操作的髒頁寫入到磁碟之後，Redo Log 的使命也就完成了，Redo Log佔用的空間就可以重用（被覆蓋寫入）。

  • Redo Log工作原理

image-20220515221500277

  • Redo Log 是為了實現事務的永續性而出現的產物。防止在發生故障的時間點，尚有髒頁未寫入表
    的 IBD 檔案中，在重新啟動 MySQL 服務的時候，根據 Redo Log 進行重做，從而達到事務的未入磁碟
    資料進行持久化這一特性。

  • Redo Log寫入機制

    Redo Log 檔案內容是以順序迴圈的方式寫入檔案，寫滿時則回溯到第一個檔案，進行覆蓋寫。

image-20220515221600311

    • write pos 是當前記錄的位置，一邊寫一邊後移，寫到最後一個檔案末尾後就回到 0 號檔案開頭；
    • checkpoint 是當前要擦除的位置，也是往後推移並且迴圈的，擦除記錄前要把記錄更新到資料檔案；
    • write pos 和 checkpoint 之間還空著的部分，可以用來記錄新的操作。如果 write pos 追上checkpoint，表示寫滿，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint推進一下。

  • Redo Log相關設定引數

    • 每個InnoDB儲存引擎至少有1個重做紀錄檔檔案組（group），每個檔案組至少有2個重做紀錄檔檔案，預設為ib_logfile0和ib_logfile1。可以通過下面一組引數控制Redo Log儲存：

      • show variables like '%innodb_log%';

    • Redo Buffer 持久化到 Redo Log 的策略，可通過 Innodb_flush_log_at_trx_commit 設定：

image-20220515221806576

  • 0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丟失一秒內的事務資料。由後臺Master執行緒每隔 1秒執行一次操作。
  • 1（預設值）：每次事務提交執行 Redo Buffer -> OS cache -> flush cache to disk，最安全，效能最差的方式。
  • 2：每次事務提交執行 Redo Buffer -> OS cache，然後由後臺Master執行緒再每隔1秒執行OS cache -> flush cache to disk 的操作。
  • 一般建議選擇取值2，因為 MySQL 掛了資料沒有損失，整個伺服器掛了才會損失1秒的事務提交數
    據。

Binlog紀錄檔

  • Binlog 記錄模式

    • Redo Log 是屬於InnoDB引擎所特有的紀錄檔，而MySQL Server也有自己的紀錄檔，即 Binary log（二進位制紀錄檔），簡稱Binlog。Binlog是記錄所有資料庫表結構變更以及表資料修改的二進位制紀錄檔，不會記錄SELECT和SHOW這類操作。Binlog紀錄檔是以事件形式記錄，還包含語句所執行的消耗時間。開啟Binlog紀錄檔有以下兩個最重要的使用場景。
      • 主從複製：在主庫中開啟Binlog功能，這樣主庫就可以把Binlog傳遞給從庫，從庫拿到Binlog後實現資料恢復達到主從資料一致性。
      • 資料恢復：通過mysqlbinlog工具來恢復資料。
    • Binlog檔名預設為「主機名_binlog-序列號」格式，例如oak_binlog-000001，也可以在組態檔中指定名稱。檔案記錄模式有STATEMENT、ROW和MIXED三種，具體含義如下。
      • ROW（row-based replication, RBR）：紀錄檔中會記錄每一行資料被修改的情況，然後在slave端對相同的資料進行修改。
        • 優點：能清楚記錄每一個行資料的修改細節，能完全實現主從資料同步和資料的恢復。
        • 缺點：批次操作，會產生大量的紀錄檔，尤其是alter table會讓紀錄檔暴漲。
      • STATMENT（statement-based replication, SBR）：每一條被修改資料的SQL都會記錄到master的Binlog中，slave在複製的時候SQL程序會解析成和原來master端執行過的相同的SQL再次執行。簡稱SQL語句複製。
        • 優點：紀錄檔量小，減少磁碟IO，提升儲存和恢復速度
        • 缺點：在某些情況下會導致主從資料不一致，比如last_insert_id()、now()等函數。
      • MIXED（mixed-based replication, MBR）：以上兩種模式的混合使用，一般會使用STATEMENT模式儲存binlog，對於STATEMENT模式無法複製的操作使用ROW模式儲存binlog，MySQL會根據執行的SQL語句選擇寫入模式。

  • Binlog 檔案結構

    • MySQL的binlog檔案中記錄的是對資料庫的各種修改操作，用來表示修改操作的資料結構是Log event。不同的修改操作對應的不同的log event。比較常用的log event有：Query event、Row event、Xid event等。binlog檔案的內容就是各種Log event的集合。

    • Binlog檔案中Log event結構如下圖所示：

image-20220515222235118

  • Binlog寫入機制

    • 根據記錄模式和操作觸發event事件生成log event（事件觸發執行機制）
    • 將事務執行過程中產生log event寫入緩衝區，每個事務執行緒都有一個緩衝區Log Event儲存在一個binlog_cache_mngr資料結構中，在該結構中有兩個緩衝區，一個是stmt_cache，用於存放不支援事務的資訊；另一個是trx_cache，用於存放支援事務的資訊。
    • 事務在提交階段會將產生的log event寫入到外部binlog檔案中。
    • 不同事務以序列方式將log event寫入binlog檔案中，所以一個事務包含的log event資訊在binlog檔案中是連續的，中間不會插入其他事務的log event。

  • Binlog檔案操作

    • 根據記錄模式和操作觸發event事件生成log event（事件觸發執行機制）
    • 將事務執行過程中產生log event寫入緩衝區，每個事務執行緒都有一個緩衝區
    • Log Event儲存在一個binlog_cache_mngr資料結構中，在該結構中有兩個緩衝區，一個是stmt_cache，用於存放不支援事務的資訊；另一個是trx_cache，用於存放支援事務的資訊。
    • 事務在提交階段會將產生的log event寫入到外部binlog檔案中。
    • 不同事務以序列方式將log event寫入binlog檔案中，所以一個事務包含的log event資訊在
      binlog檔案中是連續的，中間不會插入其他事務的log event。

  • Binlog檔案操作

    • Binlog狀態檢視

      • show variables like 'log_bin';

    • 開啟Binlog功能

      • set global log_bin = mysqllogbin; 
ERROR 1238 (HY000): Variable 'log_bin' is a read only variable

      • 需要修改my.cnf或my.ini組態檔，在[mysqld]下面增加log_bin=mysql_bin_log，重新啟動MySQL服務。

      • #log-bin=ON 
#log-bin-basename=mysqlbinlog 
binlog-format=ROW 
log-bin=mysqlbinlog

    • 使用show binlog events命令

      • show binary logs; //等價於show master logs; 

show master status; 

show binlog events; 

show binlog events in 'mysqlbinlog.000001';

    • 使用 mysqlbinlog 命令

      • mysqlbinlog "檔名" 

mysqlbinlog "檔名" > "test.sql"

    • 使用 binlog 恢復資料

      • //按指定時間恢復 
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop- datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234 

//按事件位置號恢復 
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234

      • mysqldump：定期全部備份資料庫資料。mysqlbinlog可以做增量備份和恢復操作。

    • 刪除Binlog檔案

      • purge binary logs to 'mysqlbinlog.000001'; //刪除指定檔案 

purge binary logs before '2020-04-28 00:00:00'; //刪除指定時間之前的檔案 

reset master; //清除所有檔案

      • 可以通過設定expire_logs_days引數來啟動自動清理功能。預設值為0表示沒啟用。設定為1表示超出1天binlog檔案會自動刪除掉。

  • Redo Log和 Binlog區別

    • Redo Log是屬於InnoDB引擎功能，Binlog是屬於MySQL Server自帶功能，並且是以二進位制檔案記錄。
    • Redo Log屬於物理紀錄檔，記錄該資料頁更新狀態內容，Binlog是邏輯紀錄檔，記錄更新過程。
    • Redo Log紀錄檔是迴圈寫，紀錄檔空間大小是固定，Binlog是追加寫入，寫完一個寫下一個，不會覆蓋使用。
    • Redo Log作為伺服器異常宕機後事務資料自動恢復使用，Binlog可以作為主從複製和資料恢復使用。Binlog沒有自動crash-safe能力。

推薦學習：

以上就是圖文詳解mysql架構原理的詳細內容，更多請關注TW511.COM其它相關文章！