本文轉(zhuǎn)載自微信公眾號「匠心獨(dú)運(yùn)維妙維效」，作者EverDB研發(fā)組。轉(zhuǎn)載本文請聯(lián)系匠心獨(dú)運(yùn)維妙維效公眾號。

在數(shù)據(jù)庫系統(tǒng)設(shè)計(jì)中，執(zhí)行計(jì)劃是對SQL執(zhí)行流程的形式化描述，包括了SQL執(zhí)行需要的所有算子以及其執(zhí)行次序。我們通過“EXPLAIN + SQL”指令可以詳細(xì)地查看其執(zhí)行計(jì)劃，找到性能瓶頸，為我們優(yōu)化SQL提供方向和依據(jù)。本文將從EverDB分布式數(shù)據(jù)庫角度闡述執(zhí)行計(jì)劃。

(一)分布式架構(gòu)執(zhí)行計(jì)劃

相比于集中式數(shù)據(jù)庫，分布式數(shù)據(jù)庫擁有大量分片節(jié)點(diǎn)，分別負(fù)責(zé)各自分片的數(shù)據(jù)計(jì)算與存儲，那么其執(zhí)行計(jì)劃就需要特殊的實(shí)現(xiàn)方式。對于中間件架構(gòu)分布式數(shù)據(jù)庫，通過引入分布式算子(即下文EverDB執(zhí)行計(jì)劃節(jié)點(diǎn))實(shí)現(xiàn)數(shù)據(jù)分片存儲功能，執(zhí)行計(jì)劃解析優(yōu)化，下發(fā)數(shù)據(jù)分片內(nèi)部獨(dú)立計(jì)算，協(xié)調(diào)數(shù)據(jù)分片之間并發(fā)執(zhí)行，執(zhí)行結(jié)果由中間件進(jìn)行進(jìn)一步整合進(jìn)行分組、排序等操作，是一種高效便捷的實(shí)現(xiàn)方式。

EverDB正是基于這種設(shè)計(jì)思路實(shí)現(xiàn)的執(zhí)行計(jì)劃。與傳統(tǒng)集中式數(shù)據(jù)庫相比，EverDB執(zhí)行計(jì)劃使數(shù)據(jù)庫有更高的擴(kuò)展性，支持更大量級的數(shù)據(jù)規(guī)模，更高并發(fā)的數(shù)據(jù)訪問。在處理相同負(fù)載壓力的前提下，可以充分利用各分片的存儲與計(jì)算資源，以及并行計(jì)算的優(yōu)勢達(dá)到更好的性能。

(二)EverDB執(zhí)行計(jì)劃

EverDB分布式數(shù)據(jù)庫由Grid調(diào)度層、數(shù)據(jù)節(jié)點(diǎn)、配置節(jié)點(diǎn)、管理臺組成。Grid調(diào)度層作為分布式數(shù)據(jù)庫的調(diào)度節(jié)點(diǎn)，接收并解析SQL，將SQL語句重構(gòu)改造，支持涉及分片表和非分片表兩種類型的執(zhí)行計(jì)劃分析。

圖1

EverDB的執(zhí)行計(jì)劃包括SQL在Grid調(diào)度層和后端數(shù)據(jù)節(jié)點(diǎn)的執(zhí)行流程。Grid調(diào)度節(jié)點(diǎn)的執(zhí)行計(jì)劃，主要涉及邏輯處理層和連接驅(qū)動(dòng)層兩個(gè)部分，其中邏輯處理層包括詞法、語法解析模塊，客戶端通信模塊，普通表/分片表配置、SQL重構(gòu)改造、執(zhí)行計(jì)劃樹及計(jì)劃樹節(jié)點(diǎn)。其中普通表/分片表配置用于識別SQL是否需要分片處理，并獲取分片表的存儲地址信息，完成基于分片策略的執(zhí)行計(jì)劃構(gòu)建。連接驅(qū)動(dòng)層是內(nèi)部連接池和通信協(xié)議的處理模塊，完美支持MySQL通信協(xié)議，負(fù)責(zé)在執(zhí)行計(jì)劃中將請求下推給數(shù)據(jù)節(jié)點(diǎn)。數(shù)據(jù)節(jié)點(diǎn)執(zhí)行計(jì)劃的實(shí)現(xiàn)方式可以參照MySQL執(zhí)行計(jì)劃。

圖2

以分片查詢?yōu)槔珽verDB的Grid調(diào)度節(jié)點(diǎn)的執(zhí)行計(jì)劃流程：

• SQL解析：客戶端處理線程接收到從客戶端發(fā)來的查詢請求，對SQL進(jìn)行詞法語法解析。
• SQL重構(gòu)：根據(jù)SELECT查詢表的存儲信息，可分為普通表和分片表，如果是分片表，需要進(jìn)一步根據(jù)查詢條件和數(shù)據(jù)存儲情況，重構(gòu)優(yōu)化SQL語句。比如，多分片間的跨節(jié)點(diǎn)查詢，可通過SQL重構(gòu)后下推數(shù)據(jù)節(jié)點(diǎn)執(zhí)行，或者通過建立臨時(shí)表，遷移小部分?jǐn)?shù)據(jù)來降低查詢性能損耗。
• 構(gòu)建執(zhí)行計(jì)劃：SQL經(jīng)過解析，需要構(gòu)建對應(yīng)的執(zhí)行計(jì)劃樹，即用于維護(hù)SQL執(zhí)行計(jì)劃的數(shù)據(jù)結(jié)構(gòu)，由多個(gè)執(zhí)行計(jì)劃節(jié)點(diǎn)構(gòu)成。執(zhí)行計(jì)劃節(jié)點(diǎn)是SQL執(zhí)行過程中每一步操作的執(zhí)行者，也可以看作一個(gè)個(gè)線程的執(zhí)行體，它分為很多類型，用于執(zhí)行不同的操作，比如內(nèi)部執(zhí)行節(jié)點(diǎn)、事務(wù)執(zhí)行計(jì)劃節(jié)點(diǎn)、數(shù)據(jù)遷移執(zhí)行節(jié)點(diǎn)、信息查詢節(jié)點(diǎn)、信息發(fā)送節(jié)點(diǎn)、組合排序去重節(jié)點(diǎn)等。
• 運(yùn)行執(zhí)行計(jì)劃：執(zhí)行計(jì)劃運(yùn)行過程中，對于分片表查詢，采用多線程并發(fā)的方式，加快分布式集群的處理速度。
• SQL下推：為將查詢請求下推至對應(yīng)的分片數(shù)據(jù)節(jié)點(diǎn)，EverDB通過通信模塊(即圖3中的MySQL協(xié)議適配、驅(qū)動(dòng)模塊)將查詢請求以MySQL通信協(xié)議的格式封裝成數(shù)據(jù)包，再由連接池分配的連接將數(shù)據(jù)包發(fā)送給數(shù)據(jù)節(jié)點(diǎn)，以完成分片查詢請求的下推。
• 整合結(jié)果：數(shù)據(jù)節(jié)點(diǎn)接收到來自調(diào)度節(jié)點(diǎn)的請求，進(jìn)行進(jìn)一步的SQL解析，形成針對表的執(zhí)行計(jì)劃。查詢計(jì)算完成后，數(shù)據(jù)節(jié)點(diǎn)將查詢結(jié)果反饋至調(diào)度節(jié)點(diǎn)，由調(diào)度節(jié)點(diǎn)繼續(xù)按執(zhí)行計(jì)劃樹，對所有數(shù)據(jù)節(jié)點(diǎn)返回的分片結(jié)果進(jìn)行歸并、排序等操作，將完整的查詢結(jié)果返回給客戶端，完成查詢請求。

圖3

調(diào)度節(jié)點(diǎn)在生成執(zhí)行計(jì)劃樹時(shí)，會根據(jù)分片規(guī)則對語句進(jìn)行并行執(zhí)行改造，將重構(gòu)后的多條SQL由對應(yīng)的執(zhí)行計(jì)劃樹葉節(jié)點(diǎn)下推至目標(biāo)實(shí)例，由數(shù)據(jù)節(jié)點(diǎn)實(shí)例完成該分片的查詢執(zhí)行計(jì)劃分析。

圖4介紹了執(zhí)行計(jì)劃葉節(jié)點(diǎn)將查詢請求下推至數(shù)據(jù)節(jié)點(diǎn)的通訊流程。COM_QUERY是封裝了查詢語句的協(xié)議包，由執(zhí)行計(jì)劃樹葉節(jié)點(diǎn)發(fā)送至對應(yīng)的數(shù)據(jù)節(jié)點(diǎn)進(jìn)行查詢計(jì)算。執(zhí)行計(jì)劃葉節(jié)點(diǎn)以MySQL協(xié)議流程接收、解析結(jié)果集。圖示中結(jié)果集返回的協(xié)議包及次序?yàn)椋?/p>

• ResultSetHead：結(jié)果集頭包，包含列個(gè)數(shù)信息;
• Field：結(jié)果集字段包，包含每一字段具體的信息，結(jié)果集每一字段對應(yīng)一個(gè)Field協(xié)議包;
• 所有字段信息發(fā)送結(jié)束后，后端數(shù)據(jù)節(jié)點(diǎn)發(fā)送一個(gè) EOF 協(xié)議包，開始行數(shù)據(jù)的發(fā)送;
• RowData：結(jié)果集行數(shù)據(jù)包，與Field協(xié)議包相同，每一行的數(shù)據(jù)對應(yīng)一個(gè)行數(shù)據(jù)包，因此，一次結(jié)果集發(fā)送可能會包含多個(gè)行數(shù)據(jù)協(xié)議包;
• 所有行數(shù)據(jù)包發(fā)送完畢后，服務(wù)端會再發(fā)送 EOF 協(xié)議包表示結(jié)果集發(fā)送的結(jié)束;

執(zhí)行計(jì)劃葉節(jié)點(diǎn)收到分片的查詢結(jié)果后，將各自分片結(jié)果交由父級非葉節(jié)點(diǎn)對所有分片結(jié)果做進(jìn)一步處理(如歸并、排序等)，向客戶端返回完整的查詢數(shù)據(jù)結(jié)果。

圖4

(三) 如何查看執(zhí)行計(jì)劃?

展示執(zhí)行計(jì)劃，只需在查詢的SELECT關(guān)鍵字之前增加DBSCALE EXPLAIN。具體語法如下：

DBSCALE EXPLAIN + SELECT查詢語句;

結(jié)果包含執(zhí)行計(jì)劃每一步的執(zhí)行信息，顯示執(zhí)行節(jié)點(diǎn)、執(zhí)行次序和執(zhí)行SQL內(nèi)容，SQL性能好壞也能通過執(zhí)行計(jì)劃看出來。用于分析SQL語句和表結(jié)構(gòu)的性能瓶頸。

圖5

如上圖(圖5)示例，執(zhí)行計(jì)劃返回結(jié)果分為上下兩個(gè)結(jié)果集。第一部分展示的是查詢請求從中間層Grid到數(shù)據(jù)節(jié)點(diǎn)的完整執(zhí)行計(jì)劃。結(jié)果集前兩列是SQL在中間層Grid的執(zhí)行計(jì)劃，即exec_node字段展示SQL的執(zhí)行計(jì)劃樹，data_source展示的是每一個(gè)分片執(zhí)行節(jié)點(diǎn)涉及的分片數(shù)據(jù)源。結(jié)果集其他字段則展示的是每一條分片查詢在各自數(shù)據(jù)節(jié)點(diǎn)上的執(zhí)行計(jì)劃，這塊與MySQLexplain的返回結(jié)果是相同的。第二部分展示的是執(zhí)行計(jì)劃在每個(gè)執(zhí)行節(jié)點(diǎn)上實(shí)際運(yùn)行的重構(gòu)后SQL語句，因此可能與從客戶端接收到的SQL語句不同。

• 執(zhí)行計(jì)劃中一些重要字段的說明如下：
• exec_node：執(zhí)行計(jì)劃樹的每一個(gè)執(zhí)行節(jié)點(diǎn)。整列展示了完整的執(zhí)行計(jì)劃樹，以“*”開頭表示執(zhí)行計(jì)劃樹根節(jié)點(diǎn)，“-”開頭表示執(zhí)行計(jì)劃樹子節(jié)點(diǎn)，其中短橫線越長表示節(jié)點(diǎn)層數(shù)越深。如上文示例包含*MySQLSendNodeid首字母為*號，是此例分片查詢執(zhí)行計(jì)劃樹的根節(jié)點(diǎn)。--MySQLFetchNode以“--”開頭，是執(zhí)行計(jì)劃樹的子節(jié)點(diǎn)，多個(gè)FetchNode并發(fā)查詢對應(yīng)數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)分片，再由SendNode整合多個(gè)FetchNode的查詢結(jié)果。
• data_source：數(shù)據(jù)源信息。數(shù)據(jù)源是提供數(shù)據(jù)庫連接用來具體執(zhí)行客戶端請求的數(shù)據(jù)庫實(shí)例，即MySQLFetchNode執(zhí)行查詢的實(shí)例地址。
• id：查詢中執(zhí)行select子句或操作表的順序，id相同，執(zhí)行順序由上至下;id不同，id值越大優(yōu)先級越高，越先被執(zhí)行。

select_type：查詢數(shù)據(jù)的操作類型，如下表：

table：執(zhí)行節(jié)點(diǎn)所處理的表名。

type：數(shù)據(jù)節(jié)點(diǎn)在表中找到所需行的方式，又稱“訪問類型”，表示| All | index | range | ref | eq_ref | const,system | null | 由左至右，由最差到最好。常見類型如下表：

• possible_keys：指出數(shù)據(jù)節(jié)點(diǎn)能使用哪個(gè)索引在表中找到行，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用。
• key：顯示數(shù)據(jù)節(jié)點(diǎn)在查詢中實(shí)際使用的索引，若沒有使用索引，顯示為NULL
• Note:查詢中若使用了覆蓋索引，則該索引僅出現(xiàn)在key列表中。
• key_len：表示索引中使用的字節(jié)數(shù)，可通過該列計(jì)算查詢中使用的索引的長度。key_len顯示的值為索引字段的最大可能長度，并非實(shí)際使用長度，即key_len是根據(jù)表定義計(jì)算而得，不是通過表內(nèi)檢索出的。
• ref：表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值。
• rows：表示數(shù)據(jù)節(jié)點(diǎn)根據(jù)表統(tǒng)計(jì)信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數(shù)。
• Extra：數(shù)據(jù)節(jié)點(diǎn)解決查詢的詳細(xì)信息,盡量避免出現(xiàn)：Using File Sort、Using Temporary。

第二部分包括node_id和sql兩個(gè)字段：node_id與第一部分中exec_node字段的中括號內(nèi)序號相關(guān)聯(lián)，表示exec_node每個(gè)層次中具體執(zhí)行SQL語句。具體SQL語句內(nèi)容則在“sql”字段中顯示。

當(dāng)“sql”字段中出現(xiàn)臨時(shí)表dbscale_tmp時(shí)(dbscale_tmp為EverDB保留字)，說明當(dāng)前SELECT查詢涉及跨分片查詢，系統(tǒng)性能損耗較高，需要進(jìn)一步分析SQL語句和表結(jié)構(gòu)性能瓶頸，盡可能避免使用臨時(shí)表，示例如下。

圖6

四 總結(jié)

EverDB作為一種典型的基于中間件實(shí)現(xiàn)分庫分表方案的分布式數(shù)據(jù)庫產(chǎn)品，其執(zhí)行計(jì)劃相比于傳統(tǒng)集中式數(shù)據(jù)庫的不同之處在于，既包括了SQL在底層各分片表上的執(zhí)行步驟，也包含proxy如何將SQL進(jìn)行分布式處理，提高分布式數(shù)據(jù)庫的處理性能，是EverDB基于中間件對執(zhí)行計(jì)劃一種特有的實(shí)現(xiàn)方式。

EverDB執(zhí)行計(jì)劃不管從底層數(shù)據(jù)節(jié)點(diǎn)還是中間層，SQL優(yōu)化算法方面，還有很多值得優(yōu)化改進(jìn)的地方。未來，EverDB會持續(xù)精進(jìn)自身的各項(xiàng)能力，努力成為更出色的國產(chǎn)分布式數(shù)據(jù)庫產(chǎn)品。