MySQL8.0 InnoDB并行執行-有解無憂

概述

MySQL經過多年的發展已然成為最流行的資料庫，廣泛用于互聯網行業，并逐步向各個傳統行業滲透，之所以流行，一方面是其優秀的高并發事務處理的能力，另一方面也得益于MySQL豐富的生態，MySQL在處理OLTP場景下的短查詢效果很好，但對于復雜大查詢則能力有限，最直接一點就是，對于一個SQL陳述句，MySQL最多只能使用一個CPU核來處理，在這種場景下無法發揮主機CPU多核的能力，MySQL沒有停滯不前，一直在發展，新推出的8.0.14版本第一次引入了并行查詢特性，使得check table和select count(*)型別的陳述句性能成倍提升，雖然目前使用場景還比較有限，但后續的發展值得期待，

使用方式

通過配置引數innodb_parallel_read_threads來設定并發執行緒數，就能開始并行掃描功能，默認這個值為4，我這里做一個簡單的實驗，通過sysbench匯入2億條資料，分別配置innodb_parallel_read_threads為1，2，4，8，16，32，64，測驗并行執行的效果，測驗陳述句為select count(*) from sbtest1;

橫軸是配置并發執行緒數，縱軸是陳述句執行時間，從測驗結果來看，整個并行表現還是不錯的，掃描2億條記錄，從單執行緒的18s，下降到32執行緒的1s，后面并發開再多，由于資料量有限，多執行緒的管理消耗超過了并發帶來的性能提升，不能再繼續縮短SQL執行時間，

MySQL并行執行

實際上目前MySQL的并行執行還處于非常初級階段，如下圖所示，左邊是之前MySQL串行處理單個SQL形態；中間的是目前MySQL版本提供的并行能力，InnoDB引擎并行掃描的形態；最右邊的是未來MySQL要發展的形態，優化器根據系統負載和SQL生成并行計劃，并將磁區計劃下發給執行器并行執行，并行執行不僅僅是并行掃描，還包括并行聚集，并行連接，并行分組，以及并行排序等，目前版本MySQL的上層的優化器以及執行器并沒有配套的修改，因此，下文的討論主要集中在InnoDB引擎如何實作并行掃描，主要包括磁區，并行掃描，預讀以及與執行器互動的配接器類，

磁區

并行掃描的一個核心步驟就是磁區，將掃描的資料劃分成多份，讓多個執行緒并行掃描，InnoDB引擎是索引組織表，資料以B+tree的形式存盤在磁盤上，節點的單位是頁面(block/page)，同時緩沖池中會對熱點頁面進行快取，并通過LRU演算法進行淘汰，磁區的邏輯就是，從根節點頁面出發，逐層往下掃描，當判斷某一層的分支數超過了配置的執行緒數，則停止拆分，在實作時，實際上總共會進行兩次磁區，第一次是按根節點頁的分支數劃分磁區，每個分支的最左葉子節點的記錄為左下界，并將這個記錄記為相鄰上一個分支的右上界，通過這種方式，將B+tree劃分成若干子樹，每個子樹就是一個掃描磁區，經過第一次磁區后，可能出現磁區數不能充分利用多核問題，比如配置了并行掃描執行緒為3，第一次磁區后，產生了4個磁區，那么前3個磁區并行做完后，第4個磁區至多只有一個執行緒掃描，最終效果就是不能充分利用多核資源，

二次磁區

為了解決這個問題，8.0.17版本引入了二次磁區，對于第4個磁區，繼續下探拆分，這樣多個子磁區又能并發掃描，InnoDB引擎并發掃描的最小粒度是頁面級別，具體判斷二次磁區的邏輯是，一次磁區后，若磁區數大于執行緒數，則編號大于執行緒數的磁區，需要繼續進行二次磁區；若磁區數小于執行緒數且B+tree層次很深，則所有的磁區都需要進行二次磁區，相關代碼如下：

split_point = 0;
if (ranges.size() > max_threads()) {
   //最后一批磁區進行二次磁區                                      
   split_point = (ranges.size() / max_threads()) * max_threads();          
 } else if (m_depth < SPLIT_THRESHOLD) {                                  
   /* If the tree is not very deep then don't split. For smaller tables    
   it is more expensive to split because we end up traversing more blocks*/
   split_point = max_threads();                                            
 } else {
   //如果B+tree的層次很深(層數大于或等于3，資料量很大)，則所有磁區都需要進行二次磁區
 }

無論是一次磁區，還是二次磁區，磁區邊界的邏輯都一樣，以每個磁區的最左葉子節點的記錄為左下界，并且將這個記錄記為相鄰上一個分支的右上界，這樣確保磁區足夠多，粒度足夠細，充分并行，下圖展示了配置為3的并發執行緒，掃描進行二次磁區的情況，

相關代碼如下：

create_ranges(size_t depth, size_t level)
一次磁區：
parallel_check_table
 add_scan
   partition(scan_range, level=0)  /* start at root-page */
     create_ranges(scan_range, depth=0, level=0)
   create_contexts(range, index >= split_point)
二次磁區：                                                      
split()
 partition(scan_range, level=1)
   create_ranges(depth=0,level)

并行掃描

在一次磁區后，將每個磁區掃描任務放入到一個lock-free佇列中，并行的worker執行緒從佇列中獲取任務，執行掃描任務，如果獲取的任務帶有split屬性，這個時候worker會將任務進行二次拆分，并投入到佇列中，這個程序主要包括兩個核心介面，一個是作業執行緒介面，另外一個是遍歷記錄介面，前者從佇列中獲取任務并執行，并維護統計計數；后者根據可見性獲取合適的記錄，并通過上層注入的回呼函式處理，比如計數等，

Parallel_reader::worker(size_t thread_id)

{

1.從ctx-queue提取ctx任務

2.根據ctx的split屬性，確定是否需要進一步拆分磁區(split())

3.遍歷磁區所有記錄(traverse())

4.一個磁區任務結束后，維護m_n_completed計數

5.如果m_n_compeleted計數達到ctx數目，喚醒所有worker執行緒結束

6.根據traverse介面，回傳err資訊，

}

Parallel_reader::Ctx::traverse()

{

1.根據range設定pcursor

2.找到btree，將游標定位到range的起始位置

3.判斷可見性(check_visibility)

4.如果可見，根據回呼函式計算(比如統計)

5.向后遍歷，若達到了頁面的最后一條記錄，啟動預讀機制(submit_read_ahead)

6.超出范圍后結束

}

同時在8.0.17版本還引入了預讀機制，避免因為IO瓶頸導致并行效果不佳的問題，目前預讀的執行緒數不能配置，在代碼中硬編碼為2個執行緒，每次預讀的單位是一個簇(InnoDB檔案通過段，簇，頁三級結構管理，一個簇是一組連續的頁)，根據頁面配置的大小，可能為1M或者2M，對于常見的16k頁面配置，每次預讀1M，也就是64個頁面，worker執行緒在進行掃描時，會先判斷相鄰的下一個頁面是否為簇的第一個頁面，如果是，則發起預讀任務，預讀任務同樣通過lock-free 佇列快取，worker執行緒是生產者，read-ahead-worker是消費者，由于所有磁區頁面沒有重疊，因此預讀任務也不會重復，

執行器互動(配接器)

實際上，MySQL已經封裝了一個配接器類Parallel_reader_adapter來供上層使用，為后續的更豐富的并行執行做準備，首先這個類需要解決記錄格式的問題，將引擎層掃描的記錄轉換成MySQL格式，這樣做到上下層解耦，執行器不用感知引擎層格式，統一按MySQL格式處理，整個程序是一個流水線，通過一個buffer批量存盤MySQL記錄，worker執行緒不停的將記錄從引擎層上讀上來，同時有記錄不停的被上層處理，通過buffer可以平衡讀取和處理速度的差異，確保整個程序流動起來，快取大小默認是2M，根據表的記錄行長來確定buffer可以快取多少個MySQL記錄，核心流程主要在process_rows介面中，流程如下

process_rows

{

1.將引擎記錄轉換成MySQL記錄

2.獲取本執行緒的buffer資訊(轉換了多少mysql記錄，發送了多少給上層)

3.將MySQL記錄填充進buffer，自增統計m_n_read

4.呼叫回呼函式處理(比如統計，聚合，排序等)，自增統計m_n_send

}

對于呼叫者來說，需要設定表的元資訊，以及注入處理記錄回呼函式，比如處理聚集，排序，分組的作業，回呼函式通過設定m_init_fn，m_load_fn和m_end_fn來控制，

總結

MySQL8.0引入了并行查詢雖然還比較初級，但已經讓我們看到了MySQL并行查詢的潛力，從實驗中我們也看到了開啟并行執行后，SQL陳述句執行充分發揮了多核能力，回應時間急劇下降，相信在不久的將來，8.0的會支持更多并行算子，包括并行聚集，并行連接，并行分組以及并行排序等，

參考檔案

https://dev.mysql.com/worklog/task/?id=11720

https://dev.mysql.com/worklog/task/?id=12978

https://yq.aliyun.com/articles/691516?utm_content=g_1000045831

http://mysql.taobao.org/monthly/2019/10/02/

https://www.percona.com/blog/2019/01/17/using-parallel-query-with-amazon-aurora-for-mysql/

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/80322.html

標籤：MySQL

上一篇：MySQL5.7安裝詳細教程

下一篇：MySQL基礎（4） | 視圖