摘要：本文為我司申礫在上的演講實(shí)錄。雖然這個(gè)線程做的事情已經(jīng)足夠簡(jiǎn)單，但是因?yàn)樯纤械亩紩?huì)通過一個(gè)線程來驅(qū)動(dòng)自己的狀態(tài)機(jī)，所以當(dāng)壓力足夠大的時(shí)候就會(huì)成為瓶頸。

本文為我司 Engineering VP 申礫在 TiDB DevCon 2019 上的演講實(shí)錄。在?上篇?中，申礫老師重點(diǎn)回顧了 TiDB 2.1 的特性，并分享了我們對(duì)「如何做好一個(gè)數(shù)據(jù)庫(kù)」的看法。
本篇將繼續(xù)介紹 TiDB 3.0 Beta 在穩(wěn)定性、易用性、功能性上的提升，以及接下來在 Storage Layer 和 SQL Layer 的規(guī)劃，enjoy~

2018 年年底我們開了一次用戶吐槽大會(huì)，當(dāng)時(shí)我們請(qǐng)了三個(gè) TiDB 的重度用戶，都是在生產(chǎn)環(huán)境有 10 套以上 TiDB 集群的用戶。那次大會(huì)規(guī)則是大家不能講 TiDB 的優(yōu)點(diǎn)，只能講缺點(diǎn)；研發(fā)同學(xué)要直面問題，不能辯解，直接提解決方案；當(dāng)然我們也保護(hù)用戶的安全（開個(gè)玩笑 :D），讓他們放心的來吐槽。剛剛的社區(qū)實(shí)踐分享也有點(diǎn)像吐槽大會(huì)第二季，我們也希望用戶來提問題，分享他們?cè)谑褂眠^程遇到什么坑，因?yàn)橹挥兄泵孢@些問題，才有可能改進(jìn)。所以我們?cè)?TiDB 3.0 Beta 中有了很多改進(jìn)，當(dāng)然還有一些會(huì)在后續(xù)版本中去改進(jìn)。

TiDB 3.0 版本第一個(gè)目標(biāo)就是「更穩(wěn)定」，特別是在大規(guī)模集群、高負(fù)載的情況下保持穩(wěn)定。穩(wěn)定性壓倒一切，如果你不穩(wěn)定，用戶擔(dān)驚受怕，業(yè)務(wù)時(shí)斷時(shí)續(xù)，后面的功能都是沒有用的。所以我們希望「先把事情做對(duì)，再做快」。

首先來看 TiDB 3.0 一個(gè)比較亮眼的功能——多線程 Raft。我來給大家詳細(xì)解釋一下，為什么要做這個(gè)事情，為什么我們以前不做這個(gè)事情。

這是 TiKV 一個(gè)抽象的架構(gòu)（圖 8）。中間標(biāo)紅的圖形是 RaftStore 模塊，所有的 Raft Group 都在一個(gè) TiKV 實(shí)例上，所有 Raft 狀態(tài)機(jī)的驅(qū)動(dòng)都是由一個(gè)叫做 RaftStore 的線程來做的，這個(gè)線程會(huì)驅(qū)動(dòng) Raft 狀態(tài)機(jī)，并且將 Raft Log Append 到磁盤上，剩下的包括發(fā)消息給其他 TiKV 節(jié)點(diǎn)以及 Apply Raft Log 到狀態(tài)機(jī)里面，都是由其他線程來做的。早期的時(shí)候，可能用戶的數(shù)據(jù)量沒那么大，或者吞吐表現(xiàn)不大的時(shí)候，其實(shí)是感知不到的。但是當(dāng)吞吐量或者數(shù)據(jù)量大到一定程度，就會(huì)感覺到這里其實(shí)是一個(gè)瓶頸。雖然這個(gè)線程做的事情已經(jīng)足夠簡(jiǎn)單，但是因?yàn)?TiKV 上所有的 Raft Peer 都會(huì)通過一個(gè)線程來驅(qū)動(dòng)自己的 Raft 狀態(tài)機(jī)，所以當(dāng)壓力足夠大的時(shí)候就會(huì)成為瓶頸。用戶會(huì)看到整個(gè) TiKV 的 CPU 并沒有用滿，但是為什么吞吐打不上去了？

因此在 TiDB 3.0 中做了一個(gè)比較大的改進(jìn)，就是將 RaftStore 這個(gè)線程，由一個(gè)線程變成一個(gè)線程池， TiKV 上所有 Raft Peer 的 Raft 狀態(tài)機(jī)驅(qū)動(dòng)都由線程池來做，這樣就能夠充分利用 CPU，充分利用多核，在 Region 特別多以及寫入量特別大的時(shí)候，依然能線性的提升吞吐。

通過上圖大家可以看到，隨著并發(fā)不斷加大，寫入是能夠去線性擴(kuò)展的。在早期版本中，并發(fā)到一定程度的時(shí)候，RaftStore 也會(huì)成為瓶頸，那么為什么我們之前沒有做這個(gè)事情？這個(gè)優(yōu)化效果這么明顯，之所以之前沒有做，是因?yàn)橹?Raft 這塊很多時(shí)候不會(huì)成為瓶頸，而在其他地方會(huì)成為瓶頸，比如說 RocksDB 的寫入或者 gRPC 可能會(huì)成為瓶頸，然后我們將 RaftStore 中的功能不斷的向外拆，拆到其他線程中，或者是其他線程里面做多線程，做異步等等，隨著我們的優(yōu)化不斷深入，用戶場(chǎng)景下的數(shù)據(jù)量、吞吐量不斷加大，我們發(fā)現(xiàn) RaftStore 線程已經(jīng)成為需要優(yōu)化的一個(gè)點(diǎn)，所以我們?cè)?3.0 中做了這個(gè)事情。而且之前保持單線程也是因?yàn)閱尉€程簡(jiǎn)單，「先把事情做對(duì)，然后再做快」。

第二個(gè)改進(jìn)是 Batch Message。我們的組件之間通訊選擇了 gRPC，首先是因?yàn)?gRPC 是 Google 出品，有人在維護(hù)他，第二是用起來很簡(jiǎn)單，也有很多功能（如流控、加密）可以用。但其實(shí)很多人吐嘈它性能比較慢，在知乎上大家也能看到各種問題，包括討論怎么去優(yōu)化他，很多人也有各種優(yōu)化經(jīng)驗(yàn)，我們也一直想怎么去優(yōu)化他。以前我們用的方法是來一個(gè) message 就通過 gRPC 發(fā)出去，雖然性能可能沒有那么好，或者說性能不是他最大的亮點(diǎn)，但有時(shí)候調(diào)性能不能單從一個(gè)模塊去考慮，應(yīng)該從架構(gòu)上去想，就是架構(gòu)需要為性能而設(shè)計(jì)，架構(gòu)上的改進(jìn)往往能帶來性能的質(zhì)變。

所以我們?cè)?TiDB 3.0 Beta 中設(shè)計(jì)了 Batch Message 。以前是一個(gè)一個(gè)消息的發(fā)，現(xiàn)在是按照消息的目標(biāo)分隊(duì)列，每個(gè)隊(duì)列會(huì)有一個(gè) Timer，當(dāng)消息湊到一定個(gè)數(shù)，或者是你的 Timer 到了時(shí)間（現(xiàn)在應(yīng)該設(shè)置的是 1ms，Batch 和這個(gè) Timer 數(shù)量都可以調(diào)），才會(huì)將發(fā)給同一個(gè)目的地的一組消息，打成一個(gè)包，一起發(fā)過去。有了這個(gè)架構(gòu)上的調(diào)整之后，我們就獲得了性能上的提升。

當(dāng)然大家會(huì)想，會(huì)不會(huì)在并發(fā)比較低的時(shí)候變慢了？因?yàn)槟銣惒坏阶銐虻南ⅲ悄憔鸵?Timer。其實(shí)是不會(huì)的，我們也做了一些設(shè)計(jì)，就是由對(duì)端先匯報(bào)「我當(dāng)前是否忙」，如果對(duì)端不忙，那么選擇一條一條的發(fā)，如果對(duì)端忙，那就可以一個(gè) Batch 一個(gè) Batch 的發(fā)，這是一個(gè)自適應(yīng)的 Batch Message 的一套系統(tǒng)。圖 11 右半部分是一個(gè)性能對(duì)比圖，有了 Batch Message 之后，在高并發(fā)情況下吞吐提升非常快，在低并發(fā)情況下性能并沒有下降。相信這個(gè)改進(jìn)可以給大家?guī)砗艽蟮暮锰帯?/p> 1.3 Titan

第三點(diǎn)改進(jìn)就是 Titan。CEO 劉奇在 Opening Keynote 中提到了我們新一代存儲(chǔ)引擎 Titan，我們計(jì)劃用 Titan 替換掉 RocksDB，TiDB 3.0 中已經(jīng)內(nèi)置了 Titan，但沒有默認(rèn)打開，如果大家想體驗(yàn)的話，可以通過配置文件去把 RocksDB 改成 Titan。我們?yōu)槭裁聪敫倪M(jìn) RocksDB 呢？是因?yàn)樗诖鎯?chǔ)大的 Key Value 的時(shí)候，有存儲(chǔ)空間放大和寫放大嚴(yán)重的問題。

所以我們嘗試解決這個(gè)問題。當(dāng)你寫入的 Key Value 比較大的時(shí)候，我們會(huì)做一個(gè)檢查，然后把大的 Value 放到一個(gè) Blob File 里去，而不是放到 LSM-Tree。這樣的分開存儲(chǔ)會(huì)讓 LSM-Tree 變得很小，避免了因?yàn)?LSM-Tree 比較高的時(shí)候，特別是數(shù)據(jù)量比較大時(shí)出現(xiàn)的比較嚴(yán)重的寫放大問題。有了 Titan 之后，就可以解決「單個(gè) TiKV 服務(wù)大量數(shù)據(jù)」的需求，因?yàn)橹敖ㄗh TiKV 一個(gè)實(shí)例不要高于 1T。我們后面計(jì)劃單個(gè) TiKV 實(shí)例能夠支持 2T 甚至 4T 數(shù)據(jù)，讓大家能夠節(jié)省存儲(chǔ)成本，并且能在 Key Value 比較大的時(shí)候，依然能獲得比較好的性能。

除了解決寫放大問題之外，其實(shí)還有一個(gè)好處就是我們可以加一個(gè)新的 API，比如 KeyExist，用來檢查 Key 是否存在，因?yàn)檫@時(shí) Key 和 Value 是分開存儲(chǔ)的，我們只需要檢查 Key 是否在，不需要把 Value Load 進(jìn)去。或者做 Unique Key 檢查時(shí)，可以不需要把 Key Value 取出來，只需要加個(gè)接口，看這個(gè) Key 是否存在就好了，這樣能夠很好的提升性能。

第四點(diǎn)是保持查詢計(jì)劃穩(wěn)定。這個(gè)在數(shù)據(jù)庫(kù)領(lǐng)域其實(shí)是一個(gè)非常難的問題，我們依然沒有 100% 解決這個(gè)問題，希望在 2019 年第一季度，最多到第二季度，能有一個(gè)非常好的解決方案。我們不希望當(dāng)數(shù)據(jù)量變化 、寫入變化、負(fù)載變化，查詢計(jì)劃突然變錯(cuò)，這個(gè)問題在線上使用過程中是災(zāi)難。那么為什么會(huì)跑著跑著變錯(cuò)？首先來說我們現(xiàn)在是一個(gè) Cost-based optimizers，我們會(huì)參考統(tǒng)計(jì)信息和當(dāng)前的數(shù)據(jù)的分布，來選擇后面的 plan。那么數(shù)據(jù)的分布是如何獲得的呢？我們是通過統(tǒng)計(jì)信息，比如直方圖、CM Sketch來獲取，這里就會(huì)出現(xiàn)兩個(gè)問題：

1. 統(tǒng)計(jì)信息可能是不準(zhǔn)的。統(tǒng)計(jì)信息畢竟是一個(gè)采樣，不是全量數(shù)據(jù)，會(huì)有一些數(shù)據(jù)壓縮，也會(huì)有精度上的損失。

2. 隨著數(shù)據(jù)不斷寫入，統(tǒng)計(jì)信息可能會(huì)落后。因?yàn)槲覀兒茈y 100% 保證統(tǒng)計(jì)信息和數(shù)據(jù)是 Match 的。

一個(gè)非常通用的思路是， 除了依賴于 Cost Model 之外，我們還要依賴更多的 Hint，依賴于更多啟發(fā)式規(guī)則去做 Access Path 裁減。舉個(gè)例子：

select * from t where a = x and b = y;
idx1(a, b)
idx2(b) -- pruned

大家通過直觀印象來看，我們一定會(huì)選擇第一個(gè)索引，而不是第二個(gè)索引，那么我們就可以把第二個(gè)索引裁掉，而不是因?yàn)榻y(tǒng)計(jì)信息落后了，然后估算出第二個(gè)索引的代價(jià)比較低，然后選擇第二個(gè)索引。上面就是我們最近在做的一個(gè)事情，這里只舉了一個(gè)簡(jiǎn)單的例子。

TiDB 3.0 第二個(gè)目標(biāo)是可用性，是讓 TiDB 簡(jiǎn)單易用。

在 TiDB 2.0 中，大家看一個(gè) Query 為什么慢了依賴的是 Explain，就是看查詢計(jì)劃，其實(shí)那個(gè)時(shí)候大家很多都看不懂，有時(shí)候看了也不知道哪有問題。后來我們?cè)?TiDB 2.1 中支持了 Explain Analyze，這是從 PG ?借鑒過來一個(gè)特性，就是我們真正的把它執(zhí)行一邊，然后再看看每個(gè)算子的耗時(shí)、處理的數(shù)據(jù)量，看看它到底干了一些什么事情，但其實(shí)可能還不夠細(xì)，因?yàn)檫€沒有細(xì)化到算子內(nèi)部的各種操作的耗時(shí)。

所以我們又做了一個(gè)叫 Query Tracing 的東西，其實(shí)在 TiDB 2.1 之前我們已經(jīng)做了一部分，在 TiDB 3.0 Beta 中做了一個(gè)收尾，就是我們可以將 Explain 結(jié)果轉(zhuǎn)成一種 Tracing 格式，再通過圖形化界面，把這個(gè) Tracing 的內(nèi)容展示出來，就可以看到這個(gè)算子具體干了一些什么事，每一步的消耗到底在哪里，這樣就可以知道哪里有問題了。希望大家都能在 TiDB 3.0 的版本中非常直觀的定位到 Query 慢的原因。

然后第二點(diǎn) Plan Management 其實(shí)也是為了 Plan 不穩(wěn)定這個(gè)問題做準(zhǔn)備的。雖然我們希望數(shù)據(jù)庫(kù)能自己 100% 把 Plan 選對(duì)，但是這個(gè)是非常美好的愿望，應(yīng)該還沒有任何一個(gè)數(shù)據(jù)庫(kù)能保證自己能 100% 的解決這個(gè)問題。那么在以前的版本中，出現(xiàn)問題怎么辦？一種是去 Analyze 一下，很多情況下他會(huì)變好，或者說你打開自動(dòng) Analyze 這個(gè)特性，或者自動(dòng) FeedBack 這個(gè)特性，可以一定程度上變好，但是還可能過一陣統(tǒng)計(jì)信息又落后了，又不準(zhǔn)了，Plan 又錯(cuò)了，或者由于現(xiàn)在 cost 模型的問題，有一些 Corner Case 處理不到，導(dǎo)致即使統(tǒng)計(jì)信息是準(zhǔn)確的， Plan 也選不對(duì)。

那么我們就需要一個(gè)兜底方案，讓大家遇到這個(gè)問題時(shí)不要束手無策。一種方法是讓業(yè)務(wù)去改 SQL，去加 Hint，也是可以解決的，但是跟業(yè)務(wù)去溝通可能會(huì)增加他們的使用成本或者反饋周期很長(zhǎng)，也有可能業(yè)務(wù)本身也不愿意做這個(gè)事情。

另外一種是用一種在線的方式，讓數(shù)據(jù)庫(kù)的使用者 DBA 也能非常簡(jiǎn)單給這個(gè) Plan 加 Hint。具體怎么做呢？我們和美團(tuán)的同學(xué)一起做了一個(gè)非常好的特性叫 Plan Management，就是我們有一個(gè) Plan 管理的模塊，我們可以通過 SQL 接口給某一條 Query，某一個(gè) Query 綁定 Plan，綁定 Hint，這時(shí)我們會(huì)對(duì) SQL 做指紋（把 Where 條件中的一些常量變成一個(gè)通配符，然后計(jì)算出一個(gè) SQL 的指紋），然后把這個(gè) Hint 綁定在指紋上。一條 Query 來了之后，先解成 AST，我們?cè)偕芍讣y，拿到指紋之后，Plan Hint Manager 會(huì)解析出綁定的 Plan 和 Hint，有 Plan 和 Hint 之后，我們會(huì)把 AST 中的一部分節(jié)點(diǎn)替換掉，接下來這個(gè) AST 就是一個(gè)「帶 Hint 的 AST」，然后扔給 Optimizer，Optimizer 就能根據(jù) Hint 介入查詢優(yōu)化器以及執(zhí)行計(jì)劃。如果出現(xiàn)慢的 Query，那么可以直接通過前面的 Query Tracing 去定位，再通過 Plan Management 機(jī)制在線的給數(shù)據(jù)庫(kù)手動(dòng)加 Hint，來解決慢 Query 的問題。這樣下來也就不需要業(yè)務(wù)人員去改 SQL。這個(gè)特性應(yīng)該在 TiDB 3.0 GA 正式對(duì)外提供，現(xiàn)在在內(nèi)部已經(jīng)跑得非常好了。在這里也非常感謝美團(tuán)數(shù)據(jù)庫(kù)開發(fā)同學(xué)的貢獻(xiàn)。

TiDB 3.0 中我們?cè)黾恿?Join Reorder。以前我們有一個(gè)非常簡(jiǎn)單的 Reorder 算法，就是根據(jù) Join 這個(gè)路徑上的等值條件做了一個(gè)優(yōu)先選擇，現(xiàn)在 TiDB 3.0 Beta 已經(jīng)提供了第一種 Join Reorder 算法，就是一個(gè)貪心的算法。簡(jiǎn)單來說，就是我有幾個(gè)需要 Join 的表，那我先從中選擇 Join 之后數(shù)據(jù)量最小的那個(gè)表（是真正根據(jù) Join 之后的代價(jià)來選的），然后我在剩下的表中再選一個(gè)，和這個(gè)再組成一個(gè) Join Path，這樣我們就能一定程度上解決很多 Join 的問題。比如 TPC-H 上的 Q5 以前是需要手動(dòng)加 Hint 才能跑出來，因?yàn)樗鼪]有選對(duì) Join 的路徑，但在 TiDB 3.0 Beta 中，已經(jīng)能夠自動(dòng)的選擇最好的 Join Path 解決這個(gè)問題了。

我們接下來還要再做一個(gè)基于動(dòng)態(tài)規(guī)劃的 Join Reorder 算法，很有可能會(huì)在 3.0 GA 中對(duì)外提供。 在 Join 表比較少的時(shí)候，我們用動(dòng)態(tài)規(guī)劃算法能保證找到最好的一個(gè) Join 的路徑，但是如果表非常多，比如大于十幾個(gè)表，那可能會(huì)選擇貪心的算法，因?yàn)?Join Reorder 還是比較耗時(shí)的。

說完穩(wěn)定性和易用性之外，我們?cè)倏匆幌鹿δ堋?/p>

我們現(xiàn)在做了一個(gè)插件系統(tǒng)，因?yàn)槲覀儼l(fā)現(xiàn)數(shù)據(jù)庫(kù)能做的功能太多了，只有我們來做其實(shí)不太可能，而且每個(gè)用戶有不一樣的需求，比如說這家想要一個(gè)能夠結(jié)合他們的監(jiān)控系統(tǒng)的一個(gè)模塊，那家想要一個(gè)能夠結(jié)合他們的認(rèn)證系統(tǒng)做一個(gè)模塊，所以我們希望有一個(gè)擴(kuò)展的機(jī)制，讓大家都有機(jī)會(huì)能夠在一個(gè)通用的數(shù)據(jù)庫(kù)內(nèi)核上去定制自己想要的特性。這個(gè)插件是基于 Golang 的 Plugin 系統(tǒng)。如果大家有 TiDB Server 的 Binary 和自己插件的 .so，就能在啟動(dòng) TiDB Server 時(shí)加載自己的插件，獲得自己定制的功能。

圖 17 還列舉了一些我們正在做的功能，比如白名單，審計(jì)日志，Slow Query，還有一些在 TiDB Hackathon 中誕生的項(xiàng)目，我們也想拿到插件中看看是否能夠做出來。

從圖 18 中可以看到，我們對(duì) TiDB 3.0 Beta 中做了這么多性能優(yōu)化之后，在 OLTP 這塊進(jìn)步還是比較大的，比如在 SysBench 下，無論是純讀取還是寫入，還是讀加寫，都有幾倍的提升。在解決穩(wěn)定性這個(gè)問題之后，我們?cè)谛阅芊矫鏁?huì)投入更多的精力。因?yàn)楹芏鄷r(shí)候不能把「性能」單純的當(dāng)作性能來看，很多時(shí)候慢了，可能業(yè)務(wù)就掛了，慢了就是錯(cuò)誤。

當(dāng)然 TiDB 3.0 中還有其他重要特性，這里就不詳細(xì)展開了。（TiDB 3.0 Beta Release Notes?）

剛才介紹是 3.0 Beta 一些比較核心的特性，我們還在繼續(xù)做更多的特性。

比如在存儲(chǔ)引擎層，我們對(duì) Raft 層還在改進(jìn)，比如說剛才我提到了我們有 Raft Learner，我們已經(jīng)能夠極大的減少由于調(diào)度帶來的 Raft Group 不可用的概率，但是把一個(gè) Learner 提成 Voter 再把另一個(gè) Voter 干掉的時(shí)間間隔雖然比較短，但時(shí)間間隔依然存在，所以也并不是一個(gè) 100% 安全的方案。因此我們做了 Raft Joint Consensus。以前成員變更只能一個(gè)一個(gè)來：先把 Learner 提成 Voter，再把另一個(gè) Voter 干掉。但有了 Raft Joint Consensus 之后，就能在一次操作中執(zhí)行多個(gè) ConfChange，從而把因?yàn)檎{(diào)度導(dǎo)致的 Region 不可用的概率降為零。

另外我們還在做跨數(shù)據(jù)中心的部署。前面社區(qū)實(shí)踐分享中來自北京銀行的于振華老師提到過，他們是一個(gè)兩地三中心五部分的方案。現(xiàn)在的 TiDB 已經(jīng)有一些機(jī)制能比較不錯(cuò)地處理這種場(chǎng)景，但我們能夠做更多更好的東西，比如說我們可以支持 Witness 這種角色，它只做投票，不同步數(shù)據(jù)，對(duì)帶寬的需求比較少，即使機(jī)房之間帶寬非常低，他可以參與投票。在其他節(jié)點(diǎn)失效的情況下，他可以參與選舉，決定誰是 Leader。另外我們支持通過 Follower 去讀數(shù)據(jù)，但寫入還是要走 Leader，這樣對(duì)跨機(jī)房有什么好處呢？ 就是可以讀本地機(jī)房的副本，而不是一定要讀遠(yuǎn)端機(jī)房那個(gè) Leader，但是寫入還是要走遠(yuǎn)端機(jī)房的 Leader，這就能極大的降低讀的延遲。除此之外，還有支持鏈?zhǔn)綇?fù)制，而不是都通過 Leader 去復(fù)制，直接通過本地機(jī)房復(fù)制數(shù)據(jù)。

之后我們還可以基于 Learner 做數(shù)據(jù)的 Backup。通過 learner 去拉一個(gè)鏡像，存到本地，或者通過 Learner 拉取鏡像之后的增量，做增量的物理備份。所以之后要做物理備份是通過 Learner 實(shí)時(shí)的把 TiKV 中數(shù)據(jù)做一個(gè)物理備份，包括全量和增量。當(dāng)需要恢復(fù)的時(shí)候，再通過這個(gè)備份直接恢復(fù)就好了，不需要通過 SQL 導(dǎo)出再導(dǎo)入，能比較快提升恢復(fù)速度。

在 SQL 層，我們還做了很多事情，比如?Optimizer 正在朝下一代做演進(jìn)，它是基于最先進(jìn)的 Cascades 模型。我們希望 Optimizer 能夠處理任意復(fù)雜的 Query，幫大家解決從 OLTP 到 OLAP 一整套問題，甚至更復(fù)雜的問題。比如現(xiàn)在 TiDB 只在 TiKV 上查數(shù)據(jù)，下一步還要接入TiFlash，TiFlash 的代價(jià)或者算子其實(shí)不一樣的，我們希望能夠在 TiDB 上支持多個(gè)存儲(chǔ)引擎，比如同一個(gè) Query，可以一部分算子推到 TiFlash 上去處理，一部分算子在 TiKV 上處理，在 TiFlash 上做全表掃描，TiKV 上就做 Index 點(diǎn)查，最后匯總在一起再做計(jì)算。

我們還計(jì)劃提供一個(gè)新的工具，叫?SQL Tuning Advisor。現(xiàn)在用戶遇到了慢 Query，或者想在上線業(yè)務(wù)之前做 SQL 審核和優(yōu)化建議，很多時(shí)候是人肉來做的，之后我們希望把這個(gè)過程變成自動(dòng)的。

除此之外我們還將支持向量化的引擎，就是把這個(gè)引擎進(jìn)一步做向量化。未來我們還要繼續(xù)兼容最新的 MySQL 8.0 的特性 Common Table，目前計(jì)劃以 MySQL 5.7 為兼容目標(biāo)，和社區(qū)用戶一起把 TiDB 過渡到 MySQL 8.0 兼容。

說了這么多，我個(gè)人覺得，我們做一個(gè)好的數(shù)據(jù)庫(kù)，有用的數(shù)據(jù)庫(kù)，最重要一點(diǎn)是我們有大量的老師，可以向用戶，向社區(qū)學(xué)習(xí)。不管是分享了使用 TiDB 的經(jīng)驗(yàn)和坑也好，還是去提 Issue 報(bào) Bug，或者是給 TiDB 提交了代碼，都是在幫助我們把 TiDB 做得更好，所以在這里表示一下衷心的感謝。最后再立一個(gè) flag，去年我們共寫了 24 篇 TiDB 源碼閱讀文章，今年還會(huì)寫?TiKV 源碼系列文章。我們希望把項(xiàng)目背后只有開發(fā)同學(xué)才能理解的這套邏輯講出來，讓大家知道 TiDB 是怎樣的工作的，希望今年能把這個(gè)事情做完，感謝大家。

1 月 19 日 TiDB DevCon 2019 在北京圓滿落幕，超過 750 位熱情的社區(qū)伙伴參加了此次大會(huì)。會(huì)上我們首次全面展示了全新存儲(chǔ)引擎 Titan、新生態(tài)工具 TiFlash 以及 TiDB 在云上的進(jìn)展，同時(shí)宣布 TiDB-Lightning Toolset & TiDB-DM 兩大生態(tài)工具開源，并分享了  TiDB 3.0 的特性與未來規(guī)劃，描述了我們眼中未來數(shù)據(jù)庫(kù)的模樣。此外，更有 11 位來自一線的 TiDB 用戶為大家分享了實(shí)踐經(jīng)驗(yàn)與踩過的「坑」。同時(shí)，我們也為新晉 TiDB Committer 授予了證書，并為 2018 年最佳社區(qū)貢獻(xiàn)個(gè)人、最佳社區(qū)貢獻(xiàn)團(tuán)隊(duì)頒發(fā)了榮譽(yù)獎(jiǎng)杯。