數據庫作為絕大多數應用系統儲存數據的核心系統，在用戶系統需要訪問數據時，有著至關重要的作用。在這些交互中，SQL 語言是應用與數據庫系統之間“溝通”的橋梁，它負責將應用的指令傳達給數據庫。因此，SQL 的性能好壞直接決定了這種“溝通”的效率，進而對系統的用戶響應時間、系統吞吐量以及IT設置成本等關鍵指標產生影響。

那么，什么是 SQL 診斷與調優？

SQL 診斷就是通過一些技術手段來找出“溝通”效率不高的原因或潛在影響“溝通”效率的因素，比如發現執行性能不佳的 SQL、可能存在性能瓶頸的 SQL 等。而 SQL 調優則是通過一系列的技術手段，來提高 SQL 的執行效率，解決 SQL 的性能瓶頸，從而達到提高應用與數據庫“溝通”效率的目的。

《DBA 從入門到實踐》第七期將在5月22日（周三）如期而至，為大家講解：

• ODP（OceanBase Database Proxy） SQL 路由原理。
• 如何分析 SQL 監控視圖。
• 如何閱讀和管理 OceanBase SQL 執行計劃。
• 最常見的 SQL 調優方式。
• SQL 性能問題的典型場景和排查思路。

點擊下方鏈接報名學習

【DBA從入門到實踐】第七期

內容搶“鮮”知

（一）ODP 路由原理

路由是 OceanBase 分布式數據庫中的一個重要功能，是分布式架構下，實現快速訪問數據的利器。

Partition 是 OceanBase 數據存儲的基本單元。當我們創建一張 Table 時，就會存在表和 Partition 的映射。非分區表中，不考慮主備時，一張 Table 對應一個 Partition；分區表中一個 Table 會對應多個 Partition。

路由實現了根據 OBServer 的數據分布精準訪問到數據所在的機器，還可以根據一定的策略將一致性要求不高的讀請求發送給副本機器，充分利用機器的資源。路由選擇輸入的是用戶的 SQL、用戶配置規則、OBServer 狀態，路由選擇輸出的是一個可用 OBServer 地址。

其路由實現邏輯如下圖所示：

（二）分析 SQL 監控視圖

OceanBase 數據庫 V4.x 版本中有著非常豐富的視圖，通過這些視圖可以獲取 OceanBase 集群各種數據庫對象的基本信息和實時狀態信息。這些視圖分為兩大類：數據字典視圖和動態性能視圖。

豐富的視圖展示了 OceanBase 數據庫的內部架構及系統運行的詳細狀態。通過視圖，我們可以便捷地查看 OceanBase 數據庫的系統組成及實時狀態，了解組件之間的關系，內部視圖是學習 OceanBase 數據庫的最好途徑之一，其相應的數據字典視圖見下圖。

監控指標相關的數據來源于 OceanBase 數據庫內部的動態性能視圖，所有監控指標都可以通過 SQL 語句進行訪問。動態性能視圖分為 GV$ 視圖和 V$ 視圖，外部監控系統（例如 OCP）通過在每個數據庫服務器上部署代理進程，通過 SQL 接口定期拉取本機上的監控信息（V$ 視圖），部分全局信息（例如 Root Service 相關）通過中心節點采集。監控數據統一匯報給監控系統數據庫，并按照各種維度聚合（集群維度、租戶維度、節點維度、Unit 維度），從而構建整個監控大盤。

（三）如何閱讀和管理 OceanBase SQL 執行計劃

執行計劃（Execution Plan）是對一條 SQL 查詢語句在數據庫中執行過程的描述。用戶可以通過 EXPLAIN 命令查看優化器針對指定 SQL 生成的邏輯執行計劃。如果要分析某條 SQL 的性能問題，通常需要先查看 SQL 的執行計劃，排查每一步 SQL 執行是否存在問題。因此，讀懂執行計劃是 SQL 優化的先決條件，而了解執行計劃的算子是理解 EXPLAIN 命令的關鍵。

（四）最常見的 SQL 調優方式

當用戶已經學習完如何通過 EXPLAIN 命令查看優化器針對 SQL 生成的邏輯執行計劃，以及如何通過 Hint 和 Outline 來人為控制優化器的行為，使優化器生成指定的計劃。就可以以上述內容為基礎，繼續了解 OceanBase SQL 性能調優中最基礎的內容：第一部分是統計信息和計劃緩存的介紹，第二部分是 OceanBase 數據庫的使用者需要了解的幾種性能調優手段。

（五）SQL 性能問題的典型場景和排查思路

當用戶完成了如何閱讀和管理 SQL 的執行計劃，以及常見的幾種 SQL 調優方式，就獲得了學習這一小節的基礎知識。當用戶遇到由于 SQL 原因導致的性能問題時，一般可以通過以下幾個步驟進行排查：

1. 通過全鏈路追蹤確認各階段耗時占比，確認耗時長的階段是什么？
2. 如果上一步顯示慢在 observer 模塊，則可以通過 oceanbase.gv$ob_sql_audit 分析具體是 observer 內的什么階段耗時長了？
3. 如果上一步耗時長的階段在執行階段，則先根據上文的內容判斷是否存在 buffer 表、大小賬號、硬解析等問題？
4. 如果上述問題均不存在，則需要通過 explain extended 展示的執行計劃來分析優化器的估行和真實行數是否有巨大差距，如果有明顯差距，則需要手動收集統計信息。否則就進一步考慮是需要創建更合適的索引、通過 hint 調整計劃形態、通過 hint 調整并行度等。

在該小節中，首先會為大家展示上面排查步驟中提到的幾個常被用于進行 SQL 性能問題分析的工具，然后介紹如何通過這幾個工具找到 SQL 性能優化的方向，最后會對 SQL 調優的最典型的場景和常見問題進行一個匯總。?

更多精彩內容請鎖定5月22日《DBA從入門到實踐》第七期~