SQL 诊断指南

SQL 诊断指南

更新时间：2026-04-07 20:57:20

压测环境中的 SQL 执行效率，一定程度上决定了系统的性能，因此在性能调优过程中，SQL 诊断是关键环节。本文提供基于系统视图和监控工具的诊断流程，帮助快速定位慢 SQL 并进行针对性优化。

高频 SQL 定位

通过 Plan Cache 统计高频 SQL

使用 gv$ob_plan_cache_plan_stat 视图，按 hit_count（命中次数）排序，筛选高频 SQL：

obclient> SELECT plan_id, sql_id, hit_count, avg_exe_usec, SUBSTR(statement, 1, 100)  
          FROM gv$ob_plan_cache_plan_stat  
          WHERE tenant_id = 1002  
          ORDER BY hit_count DESC  
          LIMIT 10;

示例输出：

+---------------------+----------------------------------+-----------+--------------+------------------------------------------------------------------------------------------------------+
| plan_id             | sql_id                           | hit_count | avg_exe_usec | substr(statement, 1, 100)                                                                            |
+---------------------+----------------------------------+-----------+--------------+------------------------------------------------------------------------------------------------------+
| 7020372274597948570 | 17605A1DA6B6A2150E9FBCA5D4C7653A |     14767 |          562 | SELECT row_id, column_name, column_value FROM __all_core_table WHERE table_name = ? ORDER BY row_id, |
| 7020372274597948744 | 9CA2F8D24467EB1A28CA50EE09743A86 |     14707 |          468 | SELECT * FROM __all_acquired_snapshot WHERE tenant_id = ?                                            |
| 7020372274597948743 | C1E19F19B0677FD5875F8C7C4FF30436 |     14707 |          492 | SELECT *  FROM __all_freeze_info                                                                     |
| 7020372274597948834 | 624F9288016A7704D6201261C0F494FF |     11823 |          110 | select * from __all_tenant_scheduler_job where tenant_id = ? and job = ?                             |
| 7020372274597948569 | 17605A1DA6B6A2150E9FBCA5D4C7653A |      7424 |          158 | SELECT row_id, column_name, column_value FROM __all_core_table WHERE table_name = ? ORDER BY row_id, |
| 7020372274597948812 | B6E4D946D9527AB02AFBEC16F74F2E25 |      7405 |          589 | SELECT * FROM __all_freeze_info ORDER BY frozen_scn DESC LIMIT ?                                     |
| 7020372274597948741 | C1E19F19B0677FD5875F8C7C4FF30436 |      7389 |           80 | SELECT *  FROM __all_freeze_info                                                                     |
| 7020372274597948742 | 9CA2F8D24467EB1A28CA50EE09743A86 |      7389 |           68 | SELECT * FROM __all_acquired_snapshot WHERE tenant_id = ?                                            |
|                  49 | 17605A1DA6B6A2150E9FBCA5D4C7653A |      7382 |         1012 | SELECT row_id, column_name, column_value FROM __all_core_table WHERE table_name = ? ORDER BY row_id, |
|                  49 | 17605A1DA6B6A2150E9FBCA5D4C7653A |      7381 |         1009 | SELECT row_id, column_name, column_value FROM __all_core_table WHERE table_name = ? ORDER BY row_id, |
+---------------------+----------------------------------+-----------+--------------+------------------------------------------------------------------------------------------------------+
10 rows in set

慢 SQL 采样分析

通过 SQL Audit 采集执行数据

根据目标 SQL_ID，采样指定时间段内的执行数据：

obclient> SELECT svr_ip, plan_type, elapsed_time,  
          AFFECTED_ROWS, RETURN_ROWS, tx_id,  
          usec_to_time(REQUEST_TIME),  
          SUBSTR(query_sql, 1, 30)  
          FROM gv$ob_sql_audit  
          WHERE sql_id = 'F96CE9DFB959E383828A9D91575EE97F'  
            AND request_time > time_to_usec('2021-08-25 22:00:00')  
            AND request_time < time_to_usec('2021-08-25 22:50:00')  
          ORDER BY elapsed_time DESC  
          LIMIT 10;

示例输出：

+---------------+-----------+--------------+---------------+-------------+----------------------+----------------------------+--------------------------------+
| svr_ip        | plan_type | elapsed_time | AFFECTED_ROWS | RETURN_ROWS | transaction_hash     | usec_to_time(REQUEST_TIME) | substr(query_sql, 1, 30)       |
+---------------+-----------+--------------+---------------+-------------+----------------------+----------------------------+--------------------------------+
| 10.10.10.1 |         1 |       465114 |             0 |           0 | 10023348016566894972 | 2021-08-25 22:44:08.533070 | SELECT * FROM __all_root_table |
| 10.10.10.1 |         1 |       375107 |             0 |           0 | 13001988804803062059 | 2021-08-25 22:44:08.573525 | SELECT * FROM __all_root_table |
| 10.10.10.2 |         2 |       226940 |             0 |           0 |                    0 | 2021-08-25 22:44:08.722480 | SELECT * FROM __all_root_table |
| 10.10.10.2 |         2 |       224519 |             0 |           0 |                    0 | 2021-08-25 22:44:08.730139 | SELECT * FROM __all_root_table |
| 10.10.10.1 |         1 |       220272 |             0 |           0 |  6454906702768493748 | 2021-08-25 22:44:08.745529 | SELECT * FROM __all_root_table |
| 10.10.10.3 |         2 |        78577 |             0 |           0 |                    0 | 2021-08-25 22:44:08.884916 | SELECT * FROM __all_root_table |
| 10.10.10.3 |         2 |        49034 |             0 |           0 |                    0 | 2021-08-25 22:44:08.905322 | SELECT * FROM __all_root_table |
| 10.10.10.2 |         2 |        48885 |             0 |           0 |                    0 | 2021-08-25 22:44:08.905610 | SELECT * FROM __all_root_table |
| 10.10.10.1 |         1 |        45239 |             0 |           0 | 11958340144270554107 | 2021-08-25 22:44:08.906159 | SELECT * FROM __all_root_table |
| 10.10.10.3 |         2 |        33454 |             0 |           0 |                    0 | 2021-08-25 22:44:08.920650 | SELECT * FROM __all_root_table |
+---------------+-----------+--------------+---------------+-------------+----------------------+----------------------------+--------------------------------+
10 rows in set

OCP 监控辅助分析

OceanBase Cloud Platform (OCP) 提供完善的慢 SQL 分析功能，包括：

执行计划：查看 SQL 的执行路径。
执行频率：统计 SQL 的调用次数。
耗时分布：分析执行时间的波动情况。

通过 OCP 可快速定位慢 SQL 的关键指标，提升诊断效率。

SQL 调优检查清单

定位到慢 SQL 后，需从以下维度进行排查：

资源层面：
- 租户资源（CPU、内存、IO）是否充足？
- 是否存在资源争用（如高并发导致排队）？
执行计划层面：
- 当前执行计划是否最优（对比其他可能计划）？
- 是否缺少索引或索引选择不当？
数据层面：
- affected_rows 和 return_rows 是否过大？
- 查询涉及的分区数和行数是否超出预期？
网络层面：
- 是否存在跨城/跨机访问导致的延迟？
中间结果层面：
- 对于较为复杂的 SQL，可能有中间结果 dump 到磁盘，需要确认是否符合预期？
系统层面：
- 是否有转储（Freeze）操作占用资源？
- 磁盘 IO 使用率是否过高？