歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/

本文來自OceanBase社群分享，僅限交流探討。原作者劉亦卓，OceanBase 開發工程師

------

## 前言

在我們程式設計師或 DBA 的工作中，寫 SQL 並執行就像吃一口飯一樣平常。使用黑屏客戶端時，往往要面對 SQL 編寫困難、錯誤難以快速識別、查詢結果不易讀等問題，因此通常會選擇一款圖形化化工具以除錯、執行 SQL 。那麼你是否會好奇，當我們使用視覺化的開發者工具執行一條 SQL 時，從點選執行，到展示結果、查詢執行計劃這個過程，這條 SQL 經歷了什麼呢？如果點選執行很久才能得到結果，這中間又是哪個階段出了問題呢？

ODC 作為資料庫開發者工具，致力於為使用者提供更高效、更易用的 SQL 執行與診斷方案，在 4.1.0 版本，對 SQL 執行階段的耗時也做了進一步的細化展示，以方便使用者更清晰的瞭解 SQL 耗時詳情。本文以 OB-Oracle 模式下一條 SQL 在 ODC 以及 OBServer 上的生命週期為例，介紹 ODC SQL 執行過程及耗時計算方案。

## SQL 的執行過程

### 前置處理

在 SQL 被實際執行前，首先會被解析，獲取其操作物件型別、是否加寫鎖（for update）、是否為多表查詢等基礎資訊。之後根據解析結果，若其滿足一定的條件，可能會對 SQL 進行改寫操作。

![](https://img.alicdn.com/imgextra/i1/O1CN01t545VH20NOj8EAEut_!!6000000006837-0-tps-1194-257.jpg)

### Apply SQL

改寫包括兩點，一是為了提升查詢效能，當語句為 SELECT 型別，查詢欄位中包含 * 且非 .* 的語句時，會嘗試替換為` table.*` ；二是會在 SELECT 後增加 `ROWID AS __ODC_INTERNAL_ROWID__` 的欄位，這是因為結果集編輯時，若查詢中未指定 ROWID 欄位，那麼可能會出現資料誤更新的情況。

以 `SELECT * FROM DEMO;` 為例，在發出執行請求後，會被改寫為：

`SELECT ROWID AS "__ODC_INTERNAL_ROWID__", DEMO.* FROM DEMO;`

### Validate SQL semantics

儘管對是否改寫 SQL 已經經過了一定的判定，但仍然可能出現改寫後無法執行的情況，例如查詢 GV$SYSSTAT 等不支援 ROWID 的系統檢視，那麼即便語法不存在錯誤，也會導致執行失敗。

為了避免改寫導致的執行失敗，在真實執行 SQL 之前，會執行 `EXPLAIN + SQL` ，若執行成功則說明改寫成功，執行改寫後的 SQL 並返回結果，否則仍然會採用原 SQL。

### SQL 執行

SQL 執行階段是 SQL 生命週期中最主要的階段，其經過內部處理和準備後，透過網路協議一次或多次傳送至 OceanBase Server 端，由 OBServer 進行具體執行操作，之後將結果以同樣的方式返回客戶端。

![](https://img.alicdn.com/imgextra/i2/O1CN01H2Q5Bi1RvHTSbX7hi_!!6000000002173-0-tps-2638-307.jpg)

一條 SQL 在呼叫 JDBC 驅動執行語句後，驅動首先會進行一系列準備，例如設定查詢行數限制、判斷是否透過代理連線 Server 、設定執行超時計時器 等，這個階段記作 **Jdbc prepare** 。

SQL 在從客戶端傳送至 OceanBase Server 端後，會進入等待佇列，若租戶 CPU 不足或伺服器負載過高，則此過程可能會耗費大量時間。結束排隊後，將會對其進行解析、改寫和獲取 SELECT 語句的執行計劃，該過程若未命中快取，也可能佔用較長時間。拿到物理執行計劃後，執行器才會呼叫執行緒執行該條 SQL ，並將計劃儲存至快取中。為簡化理解成本，上述一系列操作合併記作 **OBServer wait** 階段。

OBServer 執行完成後，將資料返回客戶端，透過 Get result-set 階段，從返回結果中解析出要展示的資料，至此，便是一條 SQL 的實際執行過程。

### 後置處理

在獲取到執行結果後，為了客戶端的展示、編輯及錯誤提示，還會對該條 SQL 和執行結果進行幾項後置處理。

![](https://img.alicdn.com/imgextra/i3/O1CN01qa39Xt1yzIGY2sdht_!!6000000006649-0-tps-1850-362.jpg)

### Init SQL type

針對不同型別的 SQL，Navicat、SQL Developer 等資料庫開發工具一般會給出不同的結果展示方式，例如 Navicat 對於 DML（INSERT、DELETE、UPDATE）型別語句會展示 Affected rows 影響行數，而對於 DDL、DQL 等僅提示 OK 執行成功，且展示 DQL 型別的查詢結果。

ODC 對 SQL 型別的結果展示邏輯與 Navicat 基本相同，而解析型別的過程即被記作 Init SQL type 階段，具體解析工作透過 OceanBase sql-parser 工具完成。

### Init column comment 與 Init editable Info

在解析完 SQL 型別後，如果執行結果包含一個或多個表的列資料，則 ODC 會從字典檢視 ALL_TAB_COLUMNS 中嘗試獲取相關列和表資訊，並將其暫存在快取中，以供接下來獲取列註釋和判斷結果集是否可編輯。

若當前 SQL 涉及到對錶或檢視物件的查詢，那麼在展示時會顯示列註釋。而且，若當前 SQL 為單表查詢，那麼 ODC 能夠允許使用者對結果集進行編輯；若為多表查詢，有且只有其中一張表的 ROWID 被指定，則指定 ROWID 的表的列可編輯，其餘列不可。

### Init warning message

OceanBase 資料庫提供了字典檢視 ALL_ERRORS，用於檢視當前使用者可訪問的儲存物件的錯誤。由於 SQL 視窗同樣可以執行 PL，因此在執行結束後，ODC 將嘗試查詢 ALL_ERRORS 檢視，透過物件名名稱、Schema 名稱和物件型別進行標識。若存在錯誤資訊，則將其結構化處理後返回給使用者。

至此，SQL 和結果集的後置處理也結束了，我們透過在 執行記錄 介面中的 DB 耗時，檢視上述各階段的具體耗時。

## OBServer 上的執行時間

### SQL_AUDIT 檢視

OceanBase 資料庫將每一次 SQL 執行的來源、執行狀態、詳細耗時等資訊儲存在 GV$SQL_AUDIT 系統檢視中，您可以透過該檢視來查詢 SQL 在 OBServer 端的耗時詳情。

SQL_AUDIT 檢視相關欄位如下所示：

|   欄位名稱   | 型別          | 描述                               |
| :----------: | ------------- | ---------------------------------- |
|   TRACE_ID   | VARCHAR2(128) | 該語句的 trace_id                  |
|  TENANT_ID   | NUMBER(38)    | 傳送請求的租戶 ID                  |
| REQUEST_TIME | NUMBER(38)    | 開始執行時間點，單位：微秒         |
| ELAPSED_TIME | NUMBER(38)    | 接收到請求到執行結束所消耗的總時間 |
| EXECUTE_TIME | NUMBER(38)    | 實際計劃執行所消耗的時間           |

注：在 OceanBase 4.0 版本之後，GV$SQL_AUDIT 命名更改為 GV$OB_SQL_AUDIT 。該檢視按照租戶拆分，除了系統租戶，其他租戶不能跨租戶查詢。

### SQL TRACE

此外， OceanBase 支援 Trace 功能，透過變數 OB_ENABLE_TRACE_LOG 控制。

開啟該功能後，可以使用SHOW TRACE命令來快速獲取最近一次 SQL 請求的完整日誌。該命令獲取的資料格式如下所示：

![](https://img.alicdn.com/imgextra/i4/O1CN01riUQg71ZMUJQn5wkS_!!6000000003180-2-tps-1578-992.png)

示例結果說明如下：

- Title 列包含整個 SQL 執行經歷的各個階段的資訊以及該 SQL 真實的執行路徑。若結果中有經過 Resolve、Transform、Optimizer 和 Code Generate 四個流程，則說明該 SQL 重新生成了計劃，沒有命中 Plan Cache。

- KeyValue 列包含一些執行資訊，可以用於排查問題：

1. TRACE_ID 可以作為 SQL_AUDIT 檢視中的過濾條件，快速找到該 SQL 執行資訊，同時也可以透過該 TRACE_ID 快速查詢相關的 OBServer 日誌。
2. plan_id 可以用於在 v$plan_cache_plan_explain 中檢視 Plan Cache 中快取的具體執行計劃。
3. phy_plan_type 指出該次執行計劃的型別（1 表示本地計劃/2 表示遠端計劃/3 表示分散式計劃），可以輔助 SQL 診斷。

- Time 列顯示上一個階段點到這次階段點執行耗時。如果某個 SQL 執行很慢，則透過檢視 TIME 列，能夠快速定位出具體是哪個階段執行較慢，然後再進行具體分析。假設執行耗時主要在生成計劃過程中，則只需要分析沒有命中 Plan Cache 的原因，可能是計劃淘汰後第一次執行該 SQL，或是 Plan Cache 不支援的 SQL。

## ODC 如何計算耗時

### Jdbc 準備耗時

JDBC驅動記錄了執行請求傳送和接收結果的時間節點，透過api來獲取 JDBC 網路開銷的時間，ODC 透過呼叫介面獲取兩個關鍵時間戳，將其作為計算耗時的資料來源。

Jdbc prepare 階段耗時透過計算真實傳送網路請求與呼叫執行方法之間的時間差得到。當 Server 端的查詢結果較多時，會分多次網路通訊返回資料，我們使用 Jdbc 記錄第一個資料包接收的時間戳，用於後續計算 Network consumption 階段的耗時。

![](https://img.alicdn.com/imgextra/i2/O1CN01lSBctz1C1f8hrt8Wt_!!6000000000021-0-tps-814-698.jpg)

### 實際執行耗時

在 SQL 執行完成後，ODC 會透過 SHOW TRACE 命令獲取查詢該條 SQL 在 OBServer 端的實際執行日誌。透過分析計算該日誌，可得到該次請求的 ELAPSED_TIME （接收到請求到執行結束消耗的總時間）和 EXECUTE_TIME （實際執行物理計劃所消耗的時間）。

其中 EXECUTE_TIME 即為 OBServer Execute SQL 階段耗時，且被展示為執行記錄中做外層的 DB 耗時。解析、改寫、獲取執行計劃等預處理操作的耗時為除 EXECUTE_TIME 之外時間之和，合併記作 OBServer wait 階段。

### 網路耗時

雖然 GV$SQL_AUDIT 檢視中記錄了每條 SQL 執行請求的 REQUEST_TIME ，理論上可透過該時間戳與請求傳送之間的時間差獲取到網路延時。但實際上由於該欄位取自 OBServer 本地伺服器時鐘，而不同伺服器間的·，時鐘存在時間差異，因此難以單獨計算請求傳送或接收的耗時。

ODC 將接收到第一個回包的時間節點與請求傳送的時間節點之間的差值作為請求往返時間，並減去上一步獲取到的 ELAPSED_TIME 即 OBServer 端總耗時，從而獲取到請求傳送與接收的總網路耗時，記作 Network consumption 階段。

## ODC 執行耗時展示

在 ODC 中，我們可以透過“執行記錄”介面的 “DB 耗時”功能檢視 SQL 執行各個階段的耗時，進而定位問題所在。ODC 在 4.1.0 版本，將每個階段的執行耗時時間單位進行了自適應處理，保留小數點後兩位，且對 SQL 執行階段的耗時也做了進一步的細化展示，以方便使用者更清晰的瞭解 SQL 耗時詳情。

![](https://img.alicdn.com/imgextra/i1/O1CN01UZG9lq25LAscVJ1jE_!!6000000007509-0-tps-1534-877.jpg)

文中的例子是在 OB-Oracle 模式下執行，OB-MySQL 模式與之相比，不會對 SQL 進行解析與改寫，而是直接交由驅動和 OBServer 執行，其餘階段基本相同，因此不再贅述。

## 總結

SQL 的一生很長，本文僅僅是簡要描述了其被 ODC 執行時，各個生命週期中的主要工作以及耗時是如何得到的，對 SQL 在 OceanBase Server 端內部的執行過程也僅是粗略介紹。

後續的文章中將會帶大家瞭解 ODC 的許可權管理模型，敬請期待。

歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/

分享：ODC 如何精準展現 SQL 執行的耗時？

相關文章