TiDB 最佳化器實現的基礎：統計資訊的收集

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

收集統計資訊的意義
一個 SQL 資料庫裡，最佳化器實現的好壞對效能的影響是決定性的。一個未經最佳化的執行計畫和經過充分最佳化後的執行計畫，執行時間的差別往往是成千上萬倍。而對一個 SQL 最佳化器來說，統計資訊是必不可少的條件，只有依賴統計資訊提供的資料，最佳化器才可以正確估算不同的執行計畫的執行代價，以選擇最優的執行計畫。就像一個大廚無論多麼優秀，沒有上等食材也是無法做出美味的飯菜。

統計資訊包含的內容

統計資訊有兩類，包括 Table 統計資訊和 Column 統計資訊。
Table 統計資訊包含 Row Count 和 Row Size。
Column 統計資訊包含 Null Count，Max Value，Min Value，Distinct Count 以及 Histogram。其中 Histogram 用來記錄這個 Column 的資料詳細分布，可以用來估算大於、小於或等於某個 Value 的 Row Count。

統計資訊採集的步驟

1）在 TiDB 執行 ANALYZE TABLE 語句，手動觸發收集動作。
我們知道，一個 Table 的資料往往是在不斷變化的，我們無法保證統計資訊時刻保持在最新狀態，總會有一定的誤差，如果我們不及時更新，隨著時間的推進，這個誤差可能會越來越大，影響到最佳化器的最佳化效果。
有時我們會需要讓統計資訊更新的頻率低一些來降低系統的壓力，因為每次的統計資訊收集都是開銷很大的操作。有時我們會需要立即更新統計資料，因為我們剛剛向一個表匯入了大量的資料，馬上就需要查詢。
所以定期更新統計資料的功能，我們希望可以用獨立的模組，用更靈活的策略來實現，TiDB 本身只需要支援基本的手動觸發就可以了。

2）全表掃描。
全表掃描的執行過程比較長，整個掃表的任務會被分解為一系列 Region 的小請求，每個 Region 的請求會返回該 Region 包含的 Table 的部分資料。

3）用掃描得到的資料，記錄 Row Count 和 Row Size，並對資料採樣。
掃描得到的資料量有可能會非常大，以至於無法把全部資料保留在記憶體裡進行處理，所以需要進行採樣，當採樣的機率均勻的時候，計算產生的統計資訊的誤差是可以接受的。這裡我們設定的採樣數是 1 萬，無論 Table 有多大，最後保留的樣本數不會超過 1 萬。後面會詳細介紹採樣時使用到的演算法。

4）採樣資料產生 Column 統計資訊，並儲存到 KV。
採樣得到的資料會進行計算產生 Histogram。

採樣演算法

要得到一個均勻分布的採樣池，一個最簡單的演算法是，當我掃描整個表的時候，讀到的每一行，都以一個固定的機率決定是否加入採樣池，這個機率 P =（採樣池大小/表的行數）。但是由於在掃描之前，我們並不知道一個表總共有多少行，所以如果使用這個演算法進行採樣，就需要掃描兩次，第一次擷取整個表的行數，第二次進行真正的採樣。
一個更最佳化的演算法，蓄水池演算法，可以在表的大小未知的情況下，一次掃描得到均勻分布的採樣池。

演算法的實現
假如我們的樣本池大小為 $M = 100$ ，從頭開始掃描全表，當我們讀到的記錄個數 $K < 100$ 時，我們把每一條記錄都加入採樣池，這樣保證了在記錄總數小於採樣池大小時，所有記錄都會被選中。
我們繼續掃描，當我們掃描到的第 $K = 101 條$時，我們用機率 $P = (M/K) = (100/101)$ 決定是否把這個新的記錄加入採樣池，如果加入了採樣池，採樣池的總數會超過 $M$ 的限制，這時我們需要隨機播放一箇舊的採樣丟掉，保證採樣池大小不會超過限制。
執行這樣採樣演算法一直到全表掃描結束，我們可以得到一個均勻分布的採樣池。

演算法的證明
這個演算法可以用歸納法來證明，如果表的大小 $N <= K$，所有記錄都會放入採樣池，滿足均勻分布的要求。
現在假設當讀取完 K 個元素時，採樣池滿足均勻分布的要求，採樣機率 $P = (M / K)$，當讀取第 $K + 1$ 個記錄時，我們應用蓄水池演算法，以 $P' = M / (K + 1)$ 的機率決定是否加入採樣池，這時出現了兩種情況，被加入和沒有被加入，我們繼續分析這兩種情況下，這條記錄被選中的機率。
如果記錄沒有被選中，舊樣本被保留機率是$Po1 =（1 - P'） P = (1 - M / (K + 1)) (M / K)$， 新樣本被保留的機率是 Pn1 = 0。
如果記錄被選中，採樣池中已有的採樣有 (M - 1) / M 的機率被保留，舊樣本機率是 $Po2 = P' P Po = (M / (K + 1)) (M / K) （ (M -1) / M)$，新樣本的整體機率是 $Pn2 = P' = M / (K + 1)$。
把兩種情況下的機率相加， 得到舊採樣被保留的機率 $Po = Po1 + Po2 = （1 - M / (K + 1)) (M / K) + (M / (K + 1)) (M / K) *（ (M -1) / M) = M / (K + 1)$，新採樣被保留的機率為 $Pn = Pn1 + Pn2 = 0 + M / (K + 1) = M / (K + 1)$，所有採樣被保留的機率都是 $M / (K + 1)$，滿足均勻分布的要求。

Histogram
Histogram 的類型主要有兩種，Frequency Histogram 和 Height-Balanced Histogram。
當 $NDV < Bucket Count$ 時，Frequency 可以包含全部 value 分布資訊，每一個 distinct value 佔用一個 bucke。
但是當 $NDV > bucket count$ 時，Frequency Histogram 沒有足夠的 bucket 存放 value，我們就需要用另外的 Histogram 類型，比如 Height-Balanced Histogram。
Height-Balanced Histogram 把所有 value 從小到大排序，平均放到所有 bucket 裡，但是缺點是無法記錄有哪些 popular value。
Oracle 還實現了一種 Hibrid Histogram，綜合了 Frequency Histogram 和 Height-Balanced Histogram 的優點，TiDB 實現的 Histogram 主要參考的就是 Oracle 的 Hibraid Histogram。
Hibrid Histogram 包含 N 個 bucket，我們設定的 N 的預設值是 256，每個 bucket 包含三個欄位 number，value 和 repeat，number 代表放在這個 bucket 裡的最後一個 value 在 table 裡排序後的 offset，value 就是放在這個 bucket 裡的最大的那一個 value，repeat 代表最大的 value 的個數。
Hibrid Histogram 在產生的過程中，如果一個 bucket 裝滿了，遇到下一個 value 的時候，比較一下這個新的 value 和前一個 value 是否相等，如果相等，增加 repeat 值，直到遇到一個更大的 value，換下一個 bucket 存放這個 value，這樣保證任何一個 value 只會在 一個 bucket 記憶體在，相比 Height-Balanced Histogram，可以包含更準確的 value 分布資訊。
我們用一個執行個體來說明 Hibrid Histogram 是如何儲存 value 分布資訊的。
給定 value 集合 $['a', 'a', 'b', 'c', c', 'c', 'c', 'd', 'd', ‘e’]$ 和 bucket count 3，產生的 histogram 如下：

[number, value, repeat]
[2, 'b', 0]
[6, 'c', 3]
[9, 'e', 0]

我們可以看到這個集合內， 'c' 的個數有 4 個，在第二個 bucket 裡準確記錄了 'c' 的 repeat 數量 3，這樣我們在查詢條件為 where column = 'c' 的時候，就可以準確的估算執行開銷。
統計資訊的收集，使 TiDB 的最佳化器掌握資料分布詳情，準確估算執行開銷，從而實現高效的 CBO (cost base optimization)。

這是對 PingCAP 第 15 期 NewSQL Meetup 中《TiDB 最佳化器統計資訊的採集》這一議題的乾貨整理。作為一個前沿領域的技術公司，PingCAP 希望能為在國內營造真正關注技術本身的社區和 Meetup 貢獻一分力量。自 2016 年 3 月 5 日開始 ，我們在每周六舉辦 NewSQL Meetup，通過 1-2 個議題與大家交流討論，並跟大家分享 TiDB 最新的一些進展和我們的思考，希望藉由這個機會讓更多人關注到下一代分散式資料庫。同時，我們也會定期從 Meetup 分享中篩選議題以文章形式與大家做進一步深度探討。歡迎感興趣的小夥伴關注 TiDB 項目，盼望各路大牛加入 PingCAP。