作者：李文杰 網(wǎng)易游戲計(jì)費(fèi) TiDB 負(fù)責(zé)人

在使用或運(yùn)維管理 TiDB 的過程中，大家?guī)缀醵加龅竭^ SQL 變慢的問題，尤其是查詢相關(guān)的讀變慢問題。讀變慢的問題大部分情況下都遵循一定的規(guī)律，通過經(jīng)驗(yàn)的積累可以快速的定位和優(yōu)化，不好排查的問題需要從讀 TiDB 的每個(gè)過程一一排查和分析處理。

本文針對讀 TiDB 集群的場景，總結(jié)業(yè)務(wù) SQL 在查詢突然變慢時(shí)的分析和排查思路，旨在沉淀經(jīng)驗(yàn)、共享與社區(qū)。

一. 讀原理

業(yè)務(wù) SQL 從客戶端發(fā)送到 TiDB 集群后，主要經(jīng)歷解析、生成執(zhí)行計(jì)劃、執(zhí)行查詢、返回查詢結(jié)果這幾個(gè)流程。如下所示是 TiDB 讀過程的架構(gòu)簡圖：

來自客戶端的每個(gè)讀取數(shù)據(jù)的操作，TiDB 也會(huì)將其封裝為讀事務(wù)，通常情況下事務(wù)在執(zhí)行的過程分別會(huì)與 TiDB Server、TiPD Server 和 TiKV Server 進(jìn)行交互。

TiDB?Server

● 用戶提交的業(yè)務(wù) SQL 經(jīng)過 Protocol Layer 進(jìn)行 SQL 協(xié)議轉(zhuǎn)換后，內(nèi)部 PD Client 向 TiPD Server 申請到一個(gè) TSO，此 TSO 即為讀事務(wù)的開始時(shí)間 txn_start_tso，同時(shí)也是該讀事務(wù)在全局的唯一 ID。

● TiDB Server 在解析前會(huì)將 SQL 做分類，分為 KV 點(diǎn)查詢（唯一鍵查詢，Point Get）和 DistSQL 復(fù)雜查詢（非點(diǎn)查，Copprocessor ）。

○ KV 點(diǎn)查詢跳過執(zhí)行計(jì)劃優(yōu)化階段，直接到查詢層，對于在線交易相關(guān)的 TP 場景，會(huì)大大降低響應(yīng)延遲。

○ 復(fù)雜的 SQL 查詢會(huì)被解析、轉(zhuǎn)為抽象語法樹 AST、編譯、基于 RBO/CBO 等優(yōu)化，會(huì)生成真正可以執(zhí)行的計(jì)劃。最終生成一個(gè)個(gè)對單個(gè)表訪問的數(shù)據(jù)請求。

● TiKV Client 模塊負(fù)責(zé)和存儲(chǔ)層進(jìn)行交互，查詢請求經(jīng)過 gRPC 調(diào)用，會(huì)優(yōu)先進(jìn)入 Unified Read Pool 線程池。

TiKV?Server

● Unified Read Pool 線程池負(fù)責(zé)確認(rèn)查詢的數(shù)據(jù) Snapshot 和統(tǒng)一調(diào)度查詢優(yōu)先級。

○ 新來的查詢請求其優(yōu)先級是最高的，落在 L0 隊(duì)列里。隨著查詢時(shí)間越久，為了保證系統(tǒng)整體吞吐量，慢查詢的優(yōu)先級會(huì)不斷降低，即會(huì)從 L0 調(diào)低到 L1、L2 等，隨著優(yōu)先級調(diào)低其分配到的 CPU 會(huì)減少。

○ 也就是說，一個(gè)大查詢它越慢，它的優(yōu)先級就會(huì)不斷調(diào)低，優(yōu)先級不斷調(diào)低其執(zhí)行的時(shí)間可能會(huì)更久。所以，盡可能減少大查詢事務(wù)。

● 查詢請求讀取 RocksDB 數(shù)據(jù)

○ 先去 LSM Tree 的 MemTable 查找，最新的數(shù)據(jù)會(huì)寫在這里，如果命中則返回。

○ 如果沒找到，繼續(xù)到 Immutable Memory Table 查找，找到則返回。

○ 如果再找不到，則搜查 SST 文件的緩存 Block Cache，找到則返回。

○ 如果還沒找到，則會(huì)開始讀取磁盤 SST 文件，會(huì)依次搜索 L0 至 L6 各個(gè)層級的內(nèi)容。每一層的文件都會(huì)配備一個(gè)布隆過濾器。

過濾器對一個(gè) Key 如果判斷不存在，那么它一定不存在這個(gè) SST 文件內(nèi)，此時(shí)可以跳過這個(gè)文件；

如果判斷在文件內(nèi)則它可能在可能不在，無法判斷準(zhǔn)確，此時(shí)會(huì)直接去查文件內(nèi)容，由于 SST 文件嚴(yán)格有序，所以在文件內(nèi)是效率較高的二分查找。

○ 直到找到數(shù)據(jù)后，通過 gRPC 調(diào)用返回查詢結(jié)果。

上面描述的過程，大致就是一個(gè)查詢請求在 TiDB 集群內(nèi)部的流轉(zhuǎn)步驟，這也是我們在遇到讀慢時(shí)的分析步驟。

二. 讀變慢排查思路

2.1 讀慢常規(guī)分析

業(yè)務(wù)的 SQL 變慢后，我們在 TiDB Server 的 Grafana 面板可以看到整體的或者某一百分位的請求延遲會(huì)升高，我們根據(jù)現(xiàn)象先確認(rèn)方向性的問題：是整體變慢，還是某個(gè) SQL 變慢。

● 是否整體變慢

○ 分析各個(gè)組件 TiDB、TiKV、TiPD 的響應(yīng)延遲情況

● 整體如果是正常的，繼續(xù)分析是不是某類 SQL 變慢

○ 到 Dashboard 查一查慢查詢，看一看集群熱力圖，分析一下 Top SQL

根據(jù)上面的思路，通常就可以對讀變慢的問題有一個(gè)整體的把握。

接著，和寫入變慢的分析一樣，我們可以依次排查物理硬件環(huán)境、是否有業(yè)務(wù)變更操作等情況，直到定位清楚問題。如下圖所示，業(yè)務(wù)讀 SQL 變慢的分析思路可以有下面步驟：

● 遇到問題我們應(yīng)該養(yǎng)成習(xí)慣，要先到 Dashboard 看看，對集群運(yùn)行狀況有個(gè)整體的把握

○ 查看集群熱力圖，關(guān)注集群高亮的區(qū)域，分析是否有讀熱點(diǎn)出現(xiàn)，如果有則確認(rèn)對應(yīng)的庫表、Region 等信息

熱點(diǎn)問題處理 (?https://docs.pingcap.com/zh/tidb/stable/troubleshoot-hot-spot-issues#tidb-熱點(diǎn)問題處理 )

○ 排查慢 SQL 情況，查看集群慢查詢結(jié)果，分析 SQL 慢查詢原因

○ 查看 TOP SQL 面板，分析集群的 CPU 消耗與 SQL 關(guān)聯(lián)的情況

● 物理硬件排查

○ 排查客戶端與集群之間、集群內(nèi)部 TiDB 、TiPD、TiKV 各組件之間的網(wǎng)絡(luò)問題

○ 排查集群的內(nèi)存、CPU、磁盤 IO 等情況，尤其是混合部署的集群，確認(rèn)是否存在資源相互競爭、擠兌的場景出現(xiàn)

○ 排查操作系統(tǒng)的內(nèi)核操作是否與官方建議的最佳實(shí)踐值是否一致，確認(rèn) TiDB 集群運(yùn)行在最優(yōu)的系統(tǒng)環(huán)境內(nèi)

● 業(yè)務(wù)變更

○ 確認(rèn)是否是新上線業(yè)務(wù)

○ 查看集群的 DDL Jobs，確認(rèn)是否由于在線 DDL 導(dǎo)致的問題，特別是大表加索引的場景，會(huì)消耗集群較多的資源，從而干擾集群正常的訪問請求

2.2 讀慢全鏈路排查

常規(guī)分析思路可以解決絕大部分的問題，對于剩下那些無法確認(rèn)的或較為復(fù)雜業(yè)務(wù)的問題，這時(shí)候可以分析讀請求從 TiDB Server 到 TiKV Server 、到讀 RocksDB 的整個(gè)過程，對全部查詢的鏈路逐一進(jìn)行排查，從而確認(rèn)查詢慢所在的節(jié)點(diǎn)，定位到原因后再進(jìn)行優(yōu)化即可，這一過程大致如下圖所示。

同樣地，這個(gè)是一個(gè)兜底的排查思路，適用范圍較廣、通用性較強(qiáng)，但是排查起來要花費(fèi)更多的時(shí)間和精力，也要求管理員對數(shù)據(jù)庫本身的運(yùn)行原理有一定的掌握。上面的排查步驟還是很復(fù)雜的，對用戶很不友好。

但是，目前官方已經(jīng)推出的 Dashboard 慢查詢分析功能，已經(jīng)幫我們集成和記錄了各個(gè)環(huán)節(jié)的延遲，再也不用一個(gè)一個(gè)去查找 Grafana 面板來確認(rèn)和分析了，極大地降低排查難度和縮短問題解決時(shí)長，是 TiDB 用戶的一大福音。

下面是一個(gè)慢查詢執(zhí)行時(shí)長分析的例子，可以看到慢查詢是因?yàn)?TiKV 執(zhí)行 Coprocessor 任務(wù)的累計(jì)處理時(shí)間比較久，所以導(dǎo)致整個(gè)查詢較慢， 我們再繼續(xù)針對性分析和優(yōu)化 Coprocessor 算子即可。

三. 總結(jié)

● 了解 TiDB 的讀過程，有助于我們掌握數(shù)據(jù)庫的底層執(zhí)行原理，遇到問題時(shí)可以快速定位和分析原因，也能引導(dǎo)我們更好地使用數(shù)據(jù)庫，發(fā)揮其最好的性能。

● TiDB Dashboard 是對用戶非常友好的一個(gè)官方工具，它使得我們分析慢查詢 SQL 變得更輕松和快速，大大降低了問題處理的時(shí)間，強(qiáng)烈建議使用。

● 下面的官方文檔，在分析此類問題時(shí)推薦優(yōu)先查看：

○ 集群讀寫延遲增加排查 ( 讀寫延遲增加 | PingCAP 文檔中心 )

○ 熱點(diǎn)問題處理 ( TiDB 熱點(diǎn)問題處理 | PingCAP 文檔中心 )

○ 定位慢查詢 ( 慢查詢?nèi)罩?| PingCAP 文檔中心 )

○ 分析慢查詢 ( 分析慢查詢 | PingCAP 文檔中心 )