隨著數(shù)據(jù)量的快速增長與用戶需求的變化，數(shù)據(jù)庫的管理與優(yōu)化工作日益凸顯其重要性。作為DBA及開發(fā)者，您是否曾面臨以下挑戰(zhàn)：

○? 分析場景下，在處理大規(guī)模數(shù)據(jù)的且耗時(shí)較長的查詢是，常涉及海量數(shù)據(jù)的處理及復(fù)雜的計(jì)算，如何有效地實(shí)時(shí)監(jiān)控其執(zhí)行狀態(tài)？

○ ?面對線上多節(jié)點(diǎn)部署環(huán)境中的慢SQL問題時(shí)，如何判斷是否存在分布式執(zhí)行計(jì)劃上的瓶頸？又如何精準(zhǔn)定位是哪個(gè)長尾節(jié)點(diǎn)影響了整體執(zhí)行效率？

○ ?在分析SQL執(zhí)行計(jì)劃偏離預(yù)期的原因時(shí)，如何區(qū)分是由于查詢時(shí)使用的SQL參數(shù)不具有代表性造成，還是統(tǒng)計(jì)信息不準(zhǔn)確所導(dǎo)致？怎樣判斷？

相比于傳統(tǒng)單機(jī)數(shù)據(jù)庫，分布式數(shù)據(jù)庫面對的場景更加復(fù)雜，涉及更多的鏈路，一條 SQL 的執(zhí)行可能涉及到數(shù)十個(gè)節(jié)點(diǎn)的協(xié)同工作，如果慢 SQL 無法被及時(shí)解決，可能會(huì)導(dǎo)致正常請求被阻塞、CPU 負(fù)載飆升甚至影響整個(gè)集群的可用性。

作為原生分布式數(shù)據(jù)庫，OceanBase?一直在努力提升數(shù)據(jù)庫管理和運(yùn)維效率、優(yōu)化診斷和調(diào)優(yōu)體驗(yàn)，本文將分享 OceanBase 對高效診斷數(shù)據(jù)庫方面的實(shí)踐和思考，包括：

○ ?探討在 AP 場景下面臨的執(zhí)行性能挑戰(zhàn)，并介紹常用的診斷工具；

○ ?通過案例分析展示如何利用 real-time plan monitor 進(jìn)行分布式計(jì)劃的診斷；

○ ?思考如何簡化和優(yōu)化診斷調(diào)優(yōu)過程，并介紹 OceanBase 實(shí)時(shí) SQL 診斷的應(yīng)用。

一、OceanBase AP 場景診斷實(shí)踐

（一）AP 場景執(zhí)行性能面臨的挑戰(zhàn)

在 AP（Analytical Processing，分析處理）場景下，每次執(zhí)行通常涉及大量數(shù)據(jù)，需要復(fù)雜的多維數(shù)據(jù)建模，并依賴大規(guī)模并行能力來加速查詢。

圖 1：OLAP Process

在這種場景下，分布式數(shù)據(jù)庫常見的性能問題主要包括以下幾個(gè)方面：

1. 大規(guī)模數(shù)據(jù)掃描

許多分析查詢需要處理大量數(shù)據(jù)，經(jīng)常導(dǎo)致全表掃描或大范圍數(shù)據(jù)掃描，進(jìn)而造成高 I/O 和長響應(yīng)時(shí)間。不合理的分區(qū)設(shè)計(jì)可能導(dǎo)致分區(qū)裁剪無效，使得查詢范圍擴(kuò)大，導(dǎo)致掃描更多不必要的數(shù)據(jù)。在 OceanBase 數(shù)據(jù)庫中，不同分區(qū)可能會(huì)分布在不同的節(jié)點(diǎn)上，因此跨分區(qū)查詢要求系統(tǒng)能高效地跨節(jié)點(diǎn)甚至跨數(shù)據(jù)中心進(jìn)行數(shù)據(jù)掃描。

2. 多表聚合和連接

○ ?復(fù)雜聚合函數(shù)：在分析場景中頻繁使用聚合函數(shù)（如 COUNT、SUM、AVG、MAX、MIN），在大數(shù)據(jù)集上執(zhí)行會(huì)非常耗時(shí)。

○ ?GROUP BY 處理：高基數(shù)的 GROUP BY 操作會(huì)消耗大量內(nèi)存和 CPU 資源，影響查詢性能。

○ ?大規(guī)模 JOIN 操作：分析查詢通常涉及多個(gè)大表的關(guān)聯(lián)， JOIN 操作會(huì)占用大量內(nèi)存和 CPU 資源，特別是在關(guān)聯(lián)條件選擇不恰當(dāng)時(shí)，可能會(huì)導(dǎo)致效率低下。

○ ?不合理的 JOIN 順序：優(yōu)化器選擇的 JOINS 順序如果不合理，會(huì)導(dǎo)致中間結(jié)果集增大，從而降低查詢性能。

3. 并行計(jì)算性能不達(dá)預(yù)期

由于數(shù)據(jù)分析需要處理大量數(shù)據(jù)，AP 業(yè)務(wù)通常依賴高度并行的計(jì)算能力來加速查詢，當(dāng)并行性能不達(dá)預(yù)期時(shí)，需要判斷是系統(tǒng)配置不足還是 SQL 本身存在問題。此外，由于 AP 使用的 SQL 通常執(zhí)行時(shí)間較長，而且其執(zhí)行過程對用戶不可見，如何在執(zhí)行期間監(jiān)控其實(shí)時(shí)信息和執(zhí)行狀態(tài)，也是 AP 場景使用過程中重要的一項(xiàng)功能。這些挑戰(zhàn)需要系統(tǒng)化的診斷工具和優(yōu)化策略來有效應(yīng)對，以提升 OceanBase 在 AP 場景下的性能和可靠性。

（二） OceanBase 常用診斷工具

上述問題不可避免地會(huì)帶來計(jì)劃的復(fù)雜性。當(dāng) SQL 執(zhí)行的性能不達(dá)預(yù)期，往往有可能是其中的某一個(gè)環(huán)節(jié)出現(xiàn)了卡點(diǎn)，而分布式計(jì)劃多個(gè)數(shù)據(jù)庫節(jié)點(diǎn)的處理使得這種問題環(huán)節(jié)的定位變得格外困難。

為了解決這些困難，OceanBase 提供了一系列用戶診斷和調(diào)優(yōu)工具，包括 SQL Audit、Full Link Trace、DBMS_XPLAN 工具包等。

圖 2：OceanBase Diagnostic Tools

例如，可以通過下面的步驟，初步通過 SQL Audit 視圖進(jìn)行 SQL 級(jí)別的診斷：

○ ?查看 retry 次數(shù)：如果 retry 次數(shù)很多，則可以考慮是否存在鎖沖突或切主等情況?

○ ?查看 queue time 是否很大：如果產(chǎn)生了抖動(dòng)，那些 QUEUE_TIME 非常大但是 EXCUTE_TIME 并不長的 SQL ，往往是受抖動(dòng)影響的 SQL ，而不是引起抖動(dòng)的 SQL 。因?yàn)楫a(chǎn)生抖動(dòng)的原因一般都是某條 SQL 執(zhí)行的時(shí)間很長，導(dǎo)致其他 SQL 不能及時(shí)得到 CPU 來執(zhí)行，只能一直在隊(duì)列里排隊(duì)

○ ?查看獲取執(zhí)行計(jì)劃時(shí)間（GET_PLAN_TIME）是否很長：如果是，往往說明此 SQL 沒有命中計(jì)劃而是重新去走了一次完整的生成計(jì)劃流程，一般會(huì)伴隨 IS_HIT_PLAN=0

○ ?查看 EXCUTE_TIME 是否很長：如果很長，可以通過下面的 SQL 查看是否有很長耗時(shí)的等待事件。比如發(fā)現(xiàn)此 SQL 的等待事件耗費(fèi)了很長時(shí)間在等 IO ，那么可以查看抖動(dòng)時(shí)間點(diǎn)的磁盤狀態(tài)是否正常

（三）SQL Plan Monitor 實(shí)時(shí)分析性能瓶頸

盡管我們提供了多種診斷工具，但在 AP 場景下，仍然比較缺乏 SQL 算子級(jí)別的執(zhí)行監(jiān)控支持。例如并行執(zhí)行任務(wù)劃分了多少個(gè)，是否有傾斜，HASH 沖突是否嚴(yán)重，執(zhí)行 hang 住時(shí)卡在了哪個(gè)算子上等等問題，診斷問題依賴于日志。

如果遇到了 SQL 整體層面的信息匯總分析完成，慢 SQL 仍然未定位的場景，可能問題是出在 SQL 本身而非調(diào)度階段。此時(shí)可以使用 SQL_PLAN_MONITOR 視圖進(jìn)行算子級(jí)別的詳細(xì)分析。SQL_PLAN_MONITOR 視圖是一個(gè)非常有用的工具，用于實(shí)時(shí)監(jiān)控 SQL 語句的執(zhí)行情況，通過該視圖，可以詳細(xì)了解 SQL 語句在執(zhí)行過程中的資源消耗和執(zhí)行狀態(tài)，包括算子并發(fā)數(shù)、在每個(gè)線程上的吐行、掃描行數(shù)、實(shí)際執(zhí)行時(shí)間等，用戶可以通過這些信息進(jìn)行進(jìn)一步的診斷。

1. 查詢性能瓶頸

SQL_PLAN_MONITOR 視圖記錄了執(zhí)行過程中每一個(gè)算子的吐行以及執(zhí)行時(shí)間等信息，這也是進(jìn)行性能診斷的時(shí)候最先關(guān)注的數(shù)據(jù)項(xiàng)，一般可以通過每個(gè)算子使用了多少線程（并發(fā)度），共吐出了多少行數(shù)據(jù)，以及吐出第一行和最后一行數(shù)據(jù)的時(shí)間，查詢最慢的算子。

我們以 TPC-H Q17 為例，一次執(zhí)行的記錄如下圖：

圖 3：TPC-H Q17 （LINEITEM.L_PARTKEY 無索引）

結(jié)合圖中數(shù)據(jù)與執(zhí)行計(jì)劃能夠看出，對 LINEITEM 的掃描和 7 號(hào)算子 HASH JOIN 是本次執(zhí)行的瓶頸，而左表 PART 的掃描很快就完成了，這種情況可以對右表的 join 列加索引。

添加索引后的記錄如下，連接方法由 HASH JOIN 調(diào)整為 NLJ，避免了 LINEITEM 表的全表掃描，執(zhí)行時(shí)間由 30s 降低至 4s。

圖 4：TPC-H Q17 （LINEITEM.L_PARTKEY 有索引）

2. 實(shí)時(shí) I/O 數(shù)據(jù)

從 4.2.4 版本起，SQL_PLAN_MONITOR 支持實(shí)時(shí)查看每個(gè)算子在每個(gè)線程上的耗時(shí)、I/O 數(shù)據(jù)詳情?？梢酝ㄟ^ OTHERSTAT_x_KEY 與 OTHERSTAT_x_VALUE 獲取 I/O 數(shù)據(jù)。KEY 與 VALUE 的對應(yīng)關(guān)系可以在 V$SQL_MONITOR_STATNAME 視圖中獲取，其中與 I/O 相關(guān)的字段為：

33：total io bytes read from disk

34：total bytes processed by ssstore

35：total rows processed by ssstore

36：total rows processed by memstore

一個(gè)片段如下，可以看出，該算子所有數(shù)據(jù)都是由 sstable 中掃描得到，且吐行行數(shù)不足為掃描行數(shù)的 1%，說明當(dāng)前查詢需要針對該表進(jìn)行優(yōu)化，例如調(diào)整過濾條件或在當(dāng)前過濾列上建索引。

圖 5：SQL_PLAN_MONITOR I/O 數(shù)據(jù)

3. 負(fù)載傾斜問題

當(dāng)數(shù)據(jù)在分布節(jié)點(diǎn)之間不均勻時(shí)，部分節(jié)點(diǎn)可能承載了大量數(shù)據(jù)處理任務(wù)，而其他節(jié)點(diǎn)幾乎沒有工作負(fù)載，這會(huì)造成單點(diǎn)瓶頸并影響整體性能。

例如有一個(gè)大表，有數(shù)十個(gè)分區(qū)，某個(gè)分區(qū)上存在一天的峰值數(shù)據(jù)，它的數(shù)據(jù)達(dá)到了總體的 90%。那么如果并行統(tǒng)計(jì)每分區(qū)某個(gè)字段上不同值的個(gè)數(shù)，每個(gè)線程去計(jì)算部分分區(qū)的結(jié)果，計(jì)算后匯總起來?？梢韵胂蟛⑿袌?zhí)行的效果：對于一些小分區(qū)，線程很早就做完并匯報(bào)上去，但負(fù)責(zé)大分區(qū)的線程要算很久，其它分區(qū)都在等著這個(gè)線程結(jié)束，導(dǎo)致整體性能上不去。這種場景加并行的收益很低，因?yàn)闆]有讓每個(gè)線程的負(fù)載達(dá)到平衡。

在實(shí)際業(yè)務(wù)場景中，可以通過 SQL_PLAN_MONITOR 視圖來進(jìn)行負(fù)載傾斜問題的診斷。plan monitor 視圖記錄了每個(gè)節(jié)點(diǎn)上每個(gè)線程的詳細(xì)數(shù)據(jù)，如果遇到并行性能不符合預(yù)期的表現(xiàn)，可以通過對比同個(gè)算子不同線程的記錄，可以分析是否存在長尾節(jié)點(diǎn)拖慢整個(gè)執(zhí)行過程的情況。

二、OceanBase 實(shí)時(shí) SQL 診斷

（一）開發(fā)者分析慢 SQL 的痛點(diǎn)

盡管 OceanBase 目前提供了一些診斷和調(diào)優(yōu)工具，但目前還存在一些挑戰(zhàn)，特別是對開發(fā)人員：

○ ?使用多步驟、多工具的復(fù)雜性，要求開發(fā)人員具備深入的數(shù)據(jù)庫和 OceanBase 內(nèi)核知識(shí)。

○ ?診斷和調(diào)優(yōu)過程復(fù)雜繁瑣，需要管理和維護(hù)大量的 SQL 查詢和腳本。

○ ?學(xué)習(xí)成本較高，需要專業(yè)的培訓(xùn)和長期的經(jīng)驗(yàn)積累才可以掌握 SQL 診斷方法。

（二）全新設(shè)計(jì)的實(shí)時(shí) SQL 執(zhí)行剖析

為了解決這些問題，進(jìn)一步提升 SQL 診斷的實(shí)時(shí)性和準(zhǔn)確性，我們在 ODC 4.3.1 推出了全新的 Query Profile（執(zhí)行剖析）功能，Query Profile 通過可視化方式展示了 OceanBase 4.x 提供的 real-time SQL plan monitor 功能，能夠在 SQL 執(zhí)行過程中實(shí)時(shí)查詢和展示實(shí)際計(jì)劃的執(zhí)行狀態(tài)，并詳細(xì)呈現(xiàn)計(jì)劃中每個(gè)算子的耗時(shí)和資源使用情況。

通過執(zhí)行剖析，結(jié)合 ODC 已有的執(zhí)行計(jì)劃可視化和全鏈路追蹤可視化功能，用戶可以直觀地看到執(zhí)行瓶頸，理解每一步操作的性能開銷，從而自主分析和優(yōu)化查詢性能。執(zhí)行剖析可以幫助回答以下關(guān)鍵問題：

○ ?我們要處理多少數(shù)據(jù)？

○ ?瓶頸出現(xiàn)在哪里？

○ ?哪些列在過濾器和連接中使用最頻繁？

○ ?這些列是否過濾了大部分?jǐn)?shù)據(jù)，或者它們總是提取大多數(shù)行？

TPC-H Q15 語句查詢獲得某段時(shí)間內(nèi)為總收入貢獻(xiàn)最多的供貨商（排名第一）的信息?？捎靡詻Q定對哪些頭等供貨商給予獎(jiǎng)勵(lì)、給予更多訂單、給予特別認(rèn)證、給予鼓舞等激勵(lì)。Q15 語句的特點(diǎn)是：帶有分組、排序、聚集、聚集子查詢操作并存的普通表與視圖的連接操作。我們以此條語句為例，說明執(zhí)行剖析的功能及結(jié)構(gòu)。通過 ODC 執(zhí)行后，在執(zhí)行結(jié)果處，點(diǎn)擊執(zhí)行畫像按鈕，

圖 6：查看執(zhí)行剖析

從執(zhí)行概覽可以看到一些 SQL 執(zhí)行的基本信息，例如是否為分布式計(jì)劃、是否命中計(jì)劃緩存和總耗時(shí)信息，這可以作為診斷的背景信息。

圖形視圖向我們展示了執(zhí)行計(jì)劃被調(diào)度的順序。我們通常自底向上閱讀執(zhí)行計(jì)劃，但 ODC 的執(zhí)行剖析以藍(lán)色進(jìn)度條突出顯示每個(gè)算子實(shí)際所花費(fèi)的 CPU cost，以及提供了耗時(shí)最高的 5 個(gè)節(jié)點(diǎn)排序，使識(shí)別性能瓶頸變得容易得多。通過上面的可視化視圖，能夠快速發(fā)現(xiàn)的結(jié)論：

第一，每個(gè)節(jié)點(diǎn)所花費(fèi)的時(shí)間：耗時(shí)是識(shí)別性能問題的入手點(diǎn)。從每個(gè)算子的總耗時(shí)中，我們可以快速識(shí)別瓶頸，并分析原因。在上面的示例中，查詢中運(yùn)行時(shí)間最長的節(jié)點(diǎn)是表“LINEITEM”的掃描節(jié)點(diǎn)。且可以看出主要性能瓶頸在根節(jié)點(diǎn)的左子計(jì)劃側(cè)。

第二，每個(gè)節(jié)點(diǎn)的行輸出：現(xiàn)在查看每個(gè)節(jié)點(diǎn)的行輸出。LINEITEM 表輸出約 230 萬條記錄，而右側(cè)所有算子輸出行數(shù)都為 1。

現(xiàn)在我們有了一些基本信息，且已經(jīng)了解大體的性能瓶頸所在。接下來，我們可以深入了解執(zhí)行剖析的第二部分：I/O 統(tǒng)計(jì)和算子屬性。

如上圖右側(cè)所示，這是我們查詢整體的概覽部分。我們可以查看的一些關(guān)鍵簡單指標(biāo)包括總 CPU 耗時(shí)、總 I/O 耗時(shí)、實(shí)際執(zhí)行耗時(shí)、讀取的行/字節(jié)數(shù)（關(guān)鍵問題，我們要處理多少數(shù)據(jù)）等。這些是診斷的起點(diǎn)，通常可以幫助用戶調(diào)整大多數(shù)查詢?；氐缴厦娴睦?#xff0c;我們從圖中注意到一個(gè)關(guān)鍵的事情：我們的瓶頸是計(jì)劃的左子樹。點(diǎn)擊確定的瓶頸“TABLE FULL SCAN”節(jié)點(diǎn)，查詢算子執(zhí)行詳情如下圖：

圖 7：查看算子詳情

通過右側(cè) I/O 統(tǒng)計(jì)中的 total rows processed by ssstore 字段，可以看到當(dāng)前節(jié)點(diǎn)進(jìn)行了完整的全表掃描，這說明是沒有走索引的，即便在 L_SHAPEDATE 列上我們已經(jīng)創(chuàng)建了索引，這可能是由于優(yōu)化器評(píng)估得到。

從節(jié)點(diǎn)形狀可以看出，當(dāng)前算子為分布式算子，執(zhí)行概況表明該算子的并行度為 15，傾斜度為 0.1，傾斜度較小，說明線程之間負(fù)載較為均衡，沒有拖慢整體性能的長尾節(jié)點(diǎn)。

如果想查詢每個(gè)線程執(zhí)行詳情，也可以在右側(cè)切換到不同線程，查看每個(gè)線程的吐行、吐行耗時(shí)和 rescan 次數(shù)。ODC 提供了耗時(shí)、內(nèi)存和吐行三個(gè)維度的排序，方便找到瓶頸線程。

此外，ODC 4.3.1 還對 SQL 診斷相關(guān)的功能做了全面重新設(shè)計(jì)，在一個(gè)交互頁面中同時(shí)提供 執(zhí)行剖析、執(zhí)行計(jì)劃和全鏈路診斷 信息，支持多種格式的視圖，提高分布式場景下用戶請求問題診斷效率。

圖 8：全鏈路診斷 Trace 視圖

三、寫在最后

ODC 執(zhí)行剖析功能是深入了解 OceanBase 計(jì)劃查詢機(jī)制的強(qiáng)大工具，可以幫助用戶更全面地了解每次查詢的性能細(xì)節(jié)，從而發(fā)現(xiàn) SQL 中潛在的性能瓶頸和優(yōu)化空間。

SQL 實(shí)時(shí)診斷調(diào)優(yōu)在 AP 開發(fā)具有重要意義，OceanBase 將持續(xù)增強(qiáng)這方面的能力，未來的計(jì)劃包括：

○ ?提供不同視角的并行計(jì)劃時(shí)間線視圖，如 DFO 匯總視圖、線程優(yōu)先詳情視圖和算子優(yōu)先詳情視圖。這些視圖相較于傳統(tǒng)的樹形視圖，更容易識(shí)別和分析長尾算子，有助于提高診斷效率。

○ ?支持將執(zhí)行剖析、執(zhí)行計(jì)劃和全鏈路追蹤導(dǎo)出為文件（例如 HTML），以保存 SQL 執(zhí)行現(xiàn)場。這種導(dǎo)出功能便于與支持團(tuán)隊(duì)進(jìn)行溝通和分享，促進(jìn)問題的快速解決。

○ ?進(jìn)一步的發(fā)展方向包括自助診斷和自動(dòng)調(diào)優(yōu)能力的引入。未來用戶將能夠在一個(gè)頁面上完成 SQL 性能問題的定位和解決，大大簡化調(diào)優(yōu)過程并提升了數(shù)據(jù)庫操作的效率。

通過持續(xù)的功能增強(qiáng)和優(yōu)化，OceanBase 將不斷為用戶提供更強(qiáng)大、更高效的 SQL 數(shù)據(jù)庫管理和優(yōu)化工具，以應(yīng)對更復(fù)雜的 AP 場景挑戰(zhàn)和數(shù)據(jù)處理需求。

---

ODC 是一款開源的企業(yè)級(jí)數(shù)據(jù)庫協(xié)同開發(fā)工具，獲取源碼及更多詳情，可訪問?ODC GitHub 倉庫。