摘要：雲服務環境下，如何解決客戶基於大量數據創建索引的性能問題，成為雲服務廠商的一個挑戰。華為雲GaussDB(for MySQL)通過引入並行創建索引技術，很好地解決了批量索引創建和臨時添加索引等性能瓶頸問題，幫助用戶更快建立好索引。想要進一步了解快速創建索引的秘訣，請不要錯過本文。
本文分享自華為雲社區《GaussDB(for MySQL)如何快速創建索引？華為雲數據庫資深架構師為您揭秘》，作者：華為雲數據庫資深架構師蘇斌。
蘇斌，華為雲數據庫資深架構師，擁有16年數據庫內核研發經驗，之前作為MySQL官方InnoDB團隊主要研發人員，參與和主導了多個重要特性的開發和發布。目前在華為公司負責和參與華為雲RDS主要產品RDS for MySQL和GaussDB(for MySQL)內核功能的設計和研發。
導讀
雲服務環境下，如何解決客戶基於大量數據創建索引的性能問題，成為雲服務廠商的一個挑戰。華為雲GaussDB(for MySQL)通過引入並行創建索引技術，很好地解決了批量索引創建和臨時添加索引等性能瓶頸問題，幫助用戶更快建立好索引。想要進一步了解快速創建索引的秘訣，請不要錯過本文。
關於MySQL索引
我們都知道，數據庫使用索引技術加快數據的查詢。MySQL數據庫也支持若干種索引結構提高查詢的性能（參見MySQL文檔：https://dev.mysql.com/doc/refman/8.0/en/create-index.html），其中使用最廣泛的是B+tree索引，因為B+tree索引在查詢和修改的性能之間有很好的平衡，同時其存儲和維護的代價也是比較優的。
MySQL的表本身由聚簇索引（必須是B+tree索引）表示，再加上若干個二級索引，包括B+tree索引，共同組成一個MySQL的獨立表，可以說MySQL的表是由一組索引共同組成的。我們都知道索引是一把雙刃劍，充分的索引可以更好地提升可以適配的查詢的性能，但是需要維護這些索引使得其和數據同步，所以在數據修改操作階段，更多的索引也會帶來更高的開銷。索引創建與否的權衡通常是動態的，用戶不一定能做到在表定義之初就知道需要建立哪些索引，需要隨着業務的發展變化而調整索引，這也帶來了動態索引創建的一些問題。
MySQL的索引創建邏輯
我們先看一下MySQL索引創建的邏輯。首先，MySQL索引的創建可以使用兩種不同的DDL（Data Definition Language: 數據定義語言）算法來實現。第一種是COPY算法，它非常低效，就是在兩個表之間進行數據拷貝，來完成表結構相關的修改，尤其是它要求加表鎖，現在基本不使用了。第二種是INPLACE算法，該算法不要求加鎖，因此很多DDL操作是不阻塞DML（Data Manipulation Language: 數據操縱語句）操作的，比如創建索引。該算法具體的實現在存儲引擎層面完成，可以進行更多的優化。實際上DDL語句還有一種INSTANT算法，但是它無法支持創建索引操作，這里不展開介紹。
對於INPLACE算法，在5.7版本之前，是采用索引記錄不斷地向建好的空索引插入的方式。由於插入的數據的無序性，該方法導致了明顯的性能問題和潛在的空間浪費。在5.7版本以后，MySQL優化了建索引步驟，將其改進為對已排序的索引記錄進行自底向上批量插入並且緊湊拼裝的創建方式，如果有多個索引要創建，會單獨對每個索引執行相同的算法。新的算法會經歷讀取數據、排序數據和創建索引這幾個主要步驟。
總體而言，創建索引這類DDL操作，會比普通的DML等操作要費時，而該類DDL耗時會導致用戶在繼續動態添加索引加速查詢的時候，需要等待很長的時間，極大影響業務；而且用戶的MySQL實例開啟了Binlog復制，耗時的DDL操作容易引起備庫的長時間落后。
MySQL的創建索引流程圖
雲化場景下索引創建的問題
隨着越來越多用戶把數據托管在雲服務上，以及用戶數據量的不斷增長，前述的動態添加索引導致的問題非常影響用戶體驗。同時客戶的單表數據逐漸達到幾TB甚至幾十TB，客戶對創建索引太慢所帶來的性能問題的抱怨越來越多，尤其是創建索引周期如果太長，我們可能很難找到一段合適的業務低峰期來動態創建索引，避免業務的波動。因此，如何在雲服務環境下，解決客戶基於大量數據創建索引的性能問題，成為雲服務廠商的一個挑戰。
在雲化場景下，還有一個主要場景對客戶的體驗非常重要。我們知道客戶的業務要遷移上雲，需要對數據進行大規模的遷移（華為雲提供了數據復制服務DRS工具支持各類數據遷移場景），數據遷移比較高效的方式為：
- 邏輯導出源端數據
- 在目標端建表（注意，表不含二級索引）
- 將源端導出的數據插入到目標端
- 對目標端的表建立二級索引
如果涉及動態數據同步，相關步驟會更復雜一些，由於和該主題無關，這里不展開。以上步驟中，需要重點注意的是步驟2和4，在目標端創建表的時候先不創建二級索引。這個優化對性能影響很大，尤其是一個表有很多二級索引的場景。我們知道Btree索引的插入如果是有序的，對插入性能和結果的空間利用率是最好的，因為Btree索引的分裂會在插入區域的尾部產生，同時由於分裂算法的優化，分裂產生的頁面填充率會比較高；相反地，如果是隨機插入，尤其是並發地隨機插入，很容易導致Btree索引在不同的節點進行分裂，並且分裂后的頁面填充率都處於一個半滿的狀態，導致Btree最終的一個膨脹。
有了這個背景之后，我們就容易理解上面的問題，插入表數據的時候，我們屏蔽了二級索引，等所有數據都准備好了，再采用批量建立索引的方式創建二級索引，這對於二級索引創建效率是最高的。如果不這么做，每插入一條記錄，就要去插入相應的二級索引，那么二級索引就是一個無序的隨機插入，並發起來性能會變差很多。
雖然在數據同步准備好后，批量創建二級索引是一個有效的方案，但是如果數據量很大，這么創建二級索引還是非常耗時，導致客戶在數據遷移完之后需要等待很長時間才能開展業務，這個等待周期可能是小時甚至天級別的。雖然可以考慮表級別的並發創建索引，但是這個方法也有明顯的缺點：應用場景有限，要求有多表；以及表和表之間的並發其實不是一個最有效的並發形式，相互影響比較大。
GaussDB(for MySQL)如何快速創建索引？
綜上所述，在創建索引這個點上存在兩個性能瓶頸點：一個是用戶遷移數據之后的批量索引創建；第二個是用戶臨時需要添加一個二級索引。無論哪個點，我們都需要更快的建立好索引，提升用戶的使用體驗。
華為雲GaussDB(for MySQL)引入了並行創建索引的技術，它改進了社區版MySQL創建索引只用單線程的問題，以此提高創建索引的效率，並一起解決了前述兩個痛點。前面提到的社區版創建索引邏輯是單線程的，首先存在資源利用率不夠飽滿的問題；其次創建索引過程是CPU和IO開銷交替進行的過程，在做一個操作的時候，即使不是資源競爭的操作也只有等待。多線程創建索引可以充分利用CPU和IO資源，同時有的線程在做CPU計算時，別的線程可以並發的做IO操作。
GaussDB(for MySQL)使用的並行創建索引，是一個全鏈路的並行技術。前面提到，創建索引包含了若干個階段，我們的並行創建算法，對這里的每個階段都做並行處理，從讀取數據、排序、到創建索引，都是並行操作，每一步都由指定的N個線程並發處理。它的邏輯如下圖所示：
GaussDB(for MySQL)尤其對數據的歸並排序做了多種優化，使得我們常規的歸並排序能夠充分的並行，充分利用CPU、內存和IO的資源。在並行創建索引之后的合並步驟，也使用了一套簡化的算法，正確處理各種索引結構的場景。
支持的索引和場景
GaussDB(for MySQL)的並行創建索引功能，目前支持的索引為Btree二級索引。對於virtual index二級索引，將會在不久的將來提供全面的支持，而MySQL的spatial index和fulltext index不在該並行創建索引覆蓋范圍內。
特別要注意的是，主鍵索引的創建目前也是不支持並行的，因此如果一個並行創建索引的SQL語句包含創建主鍵索引，或者前面提及的spatial index與fulltext index，那么客戶端將會收到一個告警，提示該操作不支持並行創建索引，同時該語句會采用單線程創建索引的方式執行完成。
從SQL語句的角度，如前所述，創建索引可以采用不同的算法，由於COPY算法（ALGORITHM=COPY）不是采用批量插入的方式，因此不會受益於該並行創建索引優化。而對於INPLACE算法，如果創建索引用的是非rebuild的方式，都可以受益於該優化；一旦需要使用rebuild的方式創建索引，因為涉及到主鍵索引的建立，將無法使用並行創建索引的算法。
示例
下面我們通過幾個實例來了解一下如何使用並行創建索引算法加快創建速度，以及我們的條件約束是如何生效的。
1、我們使用sysbench的表，表內有1億條數據
2、在該表的k字段建索引，采用社區默認單線程，耗時146.82s
3、通過設置innodb_rds_parallel_index_creation_threads = 4啟用4個線程建索引，可以看到建索引耗時38.72s，速度提升3.79倍。
4、假設我們要修改主鍵索引，雖然指定了多線程，但是會收到一個warning，實際上只能通過單線程建索引
注意事項
首先對innodb_rds_parallel_index_creation_threads這個參數進行一下說明，它控制了系統中所有並行DDL可以使用的總線程數，取值范圍是[1-128]。該參數取值為1表示使用原始的單線程創建索引，取值為N，表示接下來的DDL使用N個線程創建。如果一個DDL使用了100個線程在執行，那么另外一個也要使用並行的DDL且最多只能使用剩下的28個線程；而如果128個線程都被並行DDL語句占用了，新來的DDL只能走原始的單線程創建的邏輯。
雖然該並行創建索引加快了索引的創建速度，但是在具體使用場景下，還是需要有審慎的評估。我們知道在並行算法應用之后，該DDL對硬件資源的使用會盡可能的充分，這也意味着其它操作就得不到太多的資源了。因此，針對不同的場景需要具體地分析，它決定了我們如何創建索引。
對於遷移場景，由於這時候還沒有任何業務接入，用戶希望盡快完成所有索引的創建，因此可以盡量設置多線程數，比如我們是16核規格的實例，那么我們就可以把並行線程的數量指定為16，加速完成操作。
如果是用戶業務運行階段要創建索引，我們還是不希望DDL操作，對正在運行的業務如DML操作等有太多的影響。因此，這時候創建索引可以指定相對少一些的線程數量，比如2-4（或者根據CPU規格以及負載決定，同時不鼓勵並發地執行多個DDL操作）。這樣既能相對地加速創建索引的進程，也能保證DML的正常進行。
綜上所述，GaussDB(for MySQL)支持了並行創建索引，通過縮短創建索引使用的時間，很好地解決了客戶關切的兩類問題，提升了客戶的體驗。但技術無止境，在創建索引領域，還有其它的問題需要我們優化解決，例如如何減少創建索引步驟對IO的影響等等。我們后續會針對這些點進行優化，給客戶帶來更多的驚喜。
目前，華為雲GaussDB(for MySQL) 並行創建索引優化功能已上線，歡迎大家前往華為雲官網體驗：https://www.huaweicloud.com/product/gaussdb_mysql.html
附：華為雲GaussDB(for MySQL)內核專家系列文章
華為海外女科學家為您揭秘：GaussDB(for MySQL)雲棧垂直集成的力量有多大？
華為雲數據庫內核專家為您揭秘：GaussDB(for MySQL)並行查詢有多快？