關係型數據庫的 DBA 日常肯定遇到過這樣的一種場景：SQL 執行計劃選擇錯誤，這類問題的危害是很大的，常常導致業務突然卡頓，數據庫過載等不良後果。
舉個例子，假設我們有這麼一張表：
其中，姓名和性別這兩列有索引。我們設想一下，在這張表上，我們進行下面一條查詢：
SELECT * FROM t WHERE 姓名='小明' and 性別='男'
正常情況下，SQL 優化器內部會通過採樣等手段，得到姓名和性別這兩個索引的數據區分度，在這個場景下，大多數時候，「姓名」都是一個更有區分度的索引，所以優化器會選擇姓名進行查詢就能過濾掉大量的行。
但是，我們設想一個比較極端的情況，突然這個表中寫入了大量的“女性小明”：
也就是會出現這樣一種情況：對這條語句來說，使用「姓名」這個索引區分度變得不高，因爲有大量的同名小明，但是「性別」這個索引卻非常合適（只有一個男性小明）。
如果這個時候 SQL 優化器仍然選擇了姓名的索引，在業務中就會出現一條本來跑得好好的 SQL 突然變成了慢查詢。
由於 TiDB 作爲一個關係型數據庫，而且優化器也是基於代價的優化器，通常基於代價的優化器對於數據的採樣很難做到瞬時，尤其是數據量特別大表來說，總是有可能出現數據的分佈隨着業務的變化發生突變，即時採樣做到實時，不僅僅是索引的選擇，也包括 JOIN 方式的選擇，JOIN 的順序等，很難保證 100% 的情況都選對。根據我們的觀察，大多數生產環境中的 SQL 問題都是由於這個原因產生的。
知道了問題的根源，解決起來也比較簡單了，DBA 經常做的事情：找到慢查詢，使用給語句加 hint 之類的方式（給查詢語句寫註釋），告訴優化器：不要自己猜，我這邊更瞭解我的業務特徵，就按我告訴你的這麼查。
但是通過 hint 的方式，也有以下的幾個問題：
-
這些 SQL 可能不一定是手寫的，可能是 ORM 之類的數據庫框架生成的，修改 SQL 不現實。
-
即使改寫了業務層的 SQL，相當於修改了業務代碼，必然需要重新部署業務，這個可能會帶來不確定的風險。
-
雖然有 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》中也有 相關章節 介紹。歡迎大家試用並提出寶貴意見 [email protected]。
