南大通用GBase 8c数据库性能分析场景之妙用小工具（二）

在金融、电信、政务等核心业务场景中，GBase 8c 分布式数据库承载着高并发、低延迟的事务处理与分析任务。随着业务规模扩大与数据量激增，SQL 语句的执行效率直接决定了系统的整体性能与稳定性。传统“黑盒式”的性能监控手段（如仅观察 CPU、内存等资源指标）已难以快速定位响应延迟的根因——低效 SQL 往往隐藏在复杂的业务逻辑中，成为系统瓶颈的隐形杀手。为此，GBase 8c提供了丰富的工具或系统对象，辅助用户快速完成SQL性能分析。

本文继续介绍dbe_perf.statement 与 dbe_perf.statement_history视图。这两个视图如同数据库内部的“X光机”，为运维与开发人员提供了 SQL 执行全生命周期的透视能力。
1、分析SQL执行时间
字段解析
n_calls

表示这个sql执行的次数，下面的时间都是总的时间，如果要计算平均时间需要除以 n_calls。

db_time

表示这个sql 执行的总时间， 用这个时间除以 n_calls 就是每条sql执行的平均时间。这个时间的计时从 ReadCommand 接收到 client的消息开始 (timeInfoRecordStart)， 到给client 发给 ReadyForQuery消息结束 (timeInfoRecordEnd)。

CPU_time

这个时间和db_time 的计时类似，和db_time 不同的是，它调用的是 clock_gettime(CLOCK_THREAD_CPUTIME_ID， &tv) API，也就是只计算CPU时间，不计算在内核中sleep的时间。

parse_time

统计的是pg_parse_query 函数内生成查询数的时间。

plan_time

统计的是 planner 函数 优化器生成执行计划的时间。

rewrite_time

统计的是 pg_rewrite_query 函数内查询重写的时间。

execution_time

统计的是 PortalRun 函数内执行器消耗的时间。

data_io_time

统计的是读取表的block的时间，因为CN上只有元数据，所以这个值很小。

net_send_info

统计的是CN向DN发送执行计划或者下推的sql而调用 com_send的次数，消耗的时间，发送数据量的大小。

net_recv_info

同net_send_info 统计的是CN调用 com_recv的次数，消耗的时间，接收数据的大小。

清除统计信息
如果想清空统计信息，重新开始统计，可调用 reset_unique_sql 内置函数。reset_unique_sql 有三个入参。第一个入参可选 global 或 local，表示清除全局的或者本地的 sql。 第二个参数是 cleanType 用 all 即可， 第三个参数 cleanValue 用0 即可。调用完后再查视图就会发现内容已清空。

调用内置函数：

test=# select reset_unique_sql('local'， 'all'， 0);
-[ RECORD 1 ]
----+--
reset_unique_sql | t
查询视图为空：

test=# select * from dbe_perf.statement where query ~ 'UPDATE bmsql_warehouse';
(No rows)