MySQL8.0 InnoDB並行執行

時間 2020-02-23

標籤 mysql8.0 mysql innodb 並行執行欄目 MySQL 简体版

原文原文鏈接

概述

MySQL通過多年的發展已然成爲最流行的數據庫，普遍用於互聯網行業，並逐步向各個傳統行業滲透。之因此流行，一方面是其優秀的高併發事務處理的能力，另外一方面也得益於MySQL豐富的生態。MySQL在處理OLTP場景下的短查詢效果很好，但對於複雜大查詢則能力有限。最直接一點就是，對於一個SQL語句，MySQL最多隻能使用一個CPU核來處理，在這種場景下沒法發揮主機CPU多核的能力。MySQL沒有停滯不前，一直在發展，新推出的8.0.14版本第一次引入了並行查詢特性，使得check table和select count(*)類型的語句性能成倍提高。雖然目前使用場景還比較有限，但後續的發展值得期待。mysql

使用方式

經過配置參數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執行時間。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來控制。