GaussDB(for MySQL)如何快速建立索引？華為雲資料庫資深架構師為您揭祕
摘要：雲服務環境下，如何解決客戶基於大量資料建立索引的效能問題，成為雲服務廠商的一個挑戰。華為雲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)雲棧垂直整合的力量有多大？