TiDB 4.0 新特性前瞻（三）再也不用擔心我的 SQL 突然變慢了

關係型資料庫的 DBA 日常肯定遇到過這樣的一種場景：SQL 執行計劃選擇錯誤，這類問題的危害是很大的，常常導致業務突然卡頓，資料庫過載等不良後果。

舉個例子，假設我們有這麼一張表：

其中，姓名和性別這兩列有索引。我們設想一下，在這張表上，我們進行下面一條查詢：

SELECT * FROM t WHERE 姓名='小明' and 性別='男'

正常情況下，SQL 優化器內部會通過取樣等手段，得到姓名和性別這兩個索引的資料區分度，在這個場景下，大多數時候，「姓名」都是一個更有區分度的索引，所以優化器會選擇姓名進行查詢就能過濾掉大量的行。

但是，我們設想一個比較極端的情況，突然這個表中寫入了大量的 “女性小明”：

也就是會出現這樣一種情況：對這條語句來說，使用「姓名」這個索引區分度變得不高，因為有大量的同名小明，但是「性別」這個索引卻非常合適（只有一個男性小明）。

如果這個時候 SQL 優化器仍然選擇了姓名的索引，在業務中就會出現一條本來跑得好好的 SQL 突然變成了慢查詢。

由於 TiDB 作為一個關係型資料庫，而且優化器也是基於代價的優化器，通常基於代價的優化器對於資料的取樣很難做到瞬時，尤其是資料量特別大表來說，總是有可能出現資料的分佈隨著業務的變化發生突變，即時取樣做到實時，不僅僅是索引的選擇，也包括 JOIN 方式的選擇，JOIN 的順序等，很難保證 100% 的情況都選對。根據我們的觀察，大多數生產環境中的 SQL 問題都是由於這個原因產生的。

知道了問題的根源，解決起來也比較簡單了，DBA 經常做的事情：找到慢查詢，使用給語句加 hint 之類的方式（給查詢語句寫註釋），告訴優化器：不要自己猜，我這邊更瞭解我的業務特徵，就按我告訴你的這麼查。

但是通過 hint 的方式，也有以下的幾個問題：

1. 這些 SQL 可能不一定是手寫的，可能是 ORM 之類的資料庫框架生成的，修改 SQL 不現實。

2. 即使改寫了業務層的 SQL，相當於修改了業務程式碼，必然需要重新部署業務，這個可能會帶來不確定的風險。

3. 雖然有 hint，但是如果後期資料分佈發生了變化，即使優化器知道存在更好的查詢計劃，但是優化器也沒有辦法覆蓋原先的 hint。

因為有上面的問題存在，我們在 TiDB 4.0 中引入了一套全新的機制：SQL Plan Management（SPM） 幫助 DBA 解決這個問題。

我們先看看怎麼用，還是上面那個例子，DBA 只需要在資料庫中執行下面一條語句：

CREATE GLOBAL BINDING FOR 
SELECT * FROM t WHERE 姓名='小明' and 性別='男' 
USING 
SELECT * FROM t USE INDEX(性別) WHERE 姓名='小明' and 性別='男'

其實很簡單，我們引入了一個新的語法叫做，CREATE BINDING FOR …(語句) USING …(語句 2) 來給一類 SQL 查詢繫結執行計劃。

像上面通過 SPM 來修正執行計劃比起 hint 的方式來說，最明顯的區別就是：不需要修改業務的程式碼，可以由 DBA 直接實時運算元據庫系統表完成且實時生效，避免了重新上線業務的麻煩。

但我們回頭看一下，上面列出的問題 3 似乎沒解決，如果 SQL 優化器發現了更好的執行計劃，例如上面的例子，後來發現資料分佈又變化了，選擇「姓名」又是一個更好的方案了，且這個執行計劃並沒有在繫結列表中怎麼辦？這個問題在 TiDB 4.0 的 SPM 裡面，我們通過一個叫「計劃演進」的機制，很好的解決了這個問題。

顧名思義，「演進」指的就是自主的發展、進化。TiDB 4.0 的 SPM 會在設定的業務低峰時間段裡抽取一小部分資源，在後臺嘗試其他的執行計劃，如果探測出更好的執行計劃，那麼，SPM 會將這個新的計劃加入繫結列表，下次正常的查詢，TiDB 也會將這個新計劃考慮在內。

計劃演進功能，目前需要通過執行下面的 SQL 語句，設定一個全域性開關開啟：

SQL> SET GLOBAL  tidb_evolve_plan_baselines = on;

總的來說，SPM 功能使得使用者可以對 SQL 執行計劃有比較大的控制，同時又提供了靈活演進的方法，對線上執行計劃的穩定性有很大幫助，相信能讓 DBA 在使用 TiDB 的過程中更加安心。大家目前可以在 4.0.0 beta 中體驗該功能，如果需要了解更多，請檢視 相關的文件。在 TiDB 社群夥伴們合寫的開源電子書《TiDB in Action》中也有 相關章節 介紹。歡迎大家試用並提出寶貴意見 info@pingcap.com。

延展閱讀

1. TiDB 4.0 新特性前瞻（一）拍個 CT 診斷叢集熱點問題

2. TiDB 4.0 新特性前瞻（二）白話 “悲觀鎖”