数据库性能是一个永恒的话题，在解决了稳定性和高可用等温饱问题之后，数据库管理员面临最多的大概就是性能问题。性能问题的出现通常没有什么预兆，可能前一天还跑的好好的 SQL 今天就出不来数据，可能刚刚还跑的好好的程序突然就夯了，也有些系统突然夯个两三分钟等监控或应用端反馈过来问题已经消失了。
针对这种种的异常，需要管理员根据不同的问题类型从不同的维度来分析，而数据库的可分析能力也是判断一个数据库是否成熟的标志。比如有些数据库没有保存 SQL 语句的执行历史，事后的性能分析无从下手；有些数据库没有等待事件，即使数据库夯住了，也难以从数据库层面到底发生了什么。让我欣喜的是，KingbaseES 提供了丰富的数据库性能分析工具，今天我们就来看看其中的几个重要工具。
SYS_STAT_STATEMENT 工具
sys_stat_statement 是 KingbaseES 系统的一个扩展组件，提供了所有执行语句的统计信息，可以帮助分析哪种类型的查询很慢以及多久语句的执行频率等。从V9版本开始，该插件已经内置，初始化数据库的时候会被自动加载，不过需要在 kingbase.conf 中添加 sys_stat_statements.track = 'top' 配置才能正常使用。
对于V9之前的版本，可以通过以下步骤进行配置，以正常使用 sys_stat_statement 工具。
kingbase.conf 里添加预加载项
shared_preload_libraries = 'liboracle_parser, sys_stat_statements'
sys_stat_statements.max = 10000
sys_stat_statements.track = 'top'
重启数据库，再创建扩展
CREATE EXTENSION sys_stat_statements;
配置完成后会创建出 sys_stat_statements 和 sys_stat_statements_all 视图，即可通过该视图查询 SQL 语句的执行情况。
注：sys_stat_statements_all 比 sys_stat_statements 多一个 parent_queryid 字段，表示上一层 SQL 的哈希码。
select userid::regrole,total_exec_time,query from sys_stat_statements_all order by total_exec_time desc;
等待事件分析
等待事件是数据库内部记录的一种统计信息，表明数据库服务进程必须在等待事件完成后才能继续处理。等待事件揭示了可能影响性能的各种问题症状，比如缓冲区中争用、锁争用等，因此是管理员分析数据库性能问题的重要线索。
和 Oracle 类似，KingbaseES 也根据等待事件的不同原因进行了分类，典型的分类有：LightLock/Lock (锁)、BufferPin (数据缓冲区)、Activity (后台辅助进程活动)、Client (客户端)、Extension (扩展插件)、IO等等，每个分类下又有若干个具体的等待事件，真实描述了当前系统所等待的事件内容。比如常见的 AutoVacuumMain 等待事件，属于 Activity 事件类型，表示正在 autovacuum 启动器进程的主循环中等待。
开启等待事件记录需要在 kingbase.conf 中添加以下配置项，V9版本中默认已经添加该配置。
track_activities = on
配置成功后即可通过视图 sys_stat_activity，查询到会话的历史执行情况。如果某个活跃会话经常出现长时间的等待，则需要对其进一步分析以明确问题的原因。
SELECT wait_event_type, wait_event, state, count(*) FROM sys_stat_activity
group by wait_event_type, wait_event, state;
不过 sys_stat_activity 视图里记录的等待事件是瞬时信息，没有对事件时间进行累计，因此无法在故障的事后利用该视图来做进一步分析。要解决这个问题，一种方法是人工定时采样将 sys_stat_activity 视图中的数据保存下来，另一种则是我们接下来要介绍的重磅工具 -- SYS_AWR。
SYS_KWR 工具
SYS_KWR 是 KingbaseES 自动负载信息库 (Kingbase Auto Workload Repertories) 的简称，通过周期性自动记录性能统计相关的快照，分析出 KingbaseES 的操作系统运行环境、数据库时间组成、等待事件和 TOP SQL 等性能指标，为数据库性能调优提供指导。
KWR 依赖内核统计模块采集性能统计数据，建议开启以下 GUC 参数，否则 KWR 报告里会缺失部分内容。具体的参数说明可参阅官方手册，这里不一一赘述。
-- 信息收集相关参数
track_sql = on
track_instance = on
track_wait_timing = on
track_counts = on
track_io_timing = on
track_functions = 'all'
sys_kwr.track_objects = off
sys_kwr.track_os = on
sys_stat_statements.track = 'top'
-- KWR 管理相关参数
sys_kwr.enable = off
sys_kwr.topn = 20
sys_kwr.history_days = 8
sys_kwr.interval = 60
sys_kwr.language = 'chinese'
开启了 KWR 自动收集后，根据设定好的时间会自动生成快照，在需要的时候可以通过 perf.kwr_report 命令生成出指定时间段的报告用于问题分析。报告的格式和 Oracle AWR 比较相似(颜值略差^_^)，基本上该有的数据都有了，对于大多数和数据库相关的性能问题分析也够用。
KWR 是取两个时间段的快照，通过快照前后数据库统计指标的增量变化，来判断在这个时间段是否存在异常。对于需要更细致的分析某些问题的场景，比如我们可能需要分析每条 SQL 的执行情况，对于 KWR 来说就有些力不从心，这时候我们需要另外一个利器 -- SYS_KSH 工具。
SYS_KSH 工具
SYS_KSH 是在 KingbaseES V9 版本中引入的新功能，以每秒采样的方式进行会话和数据收集，采集到的数据被放入内存的 RingBuf 队列中，采集的数据主要包括：会话、应用、等待事件、命令类型、 QueryId 等。基于这些数据，管理员就能够很方便的分析过去某个时间段数据库执行了哪些 SQL，这些 SQL 的执行情况如何，是否存在异常。
KSH 功能在 KWR 插件中实现，如果配置了 sys_ksh.enable=on，会自动创建 sys_kwr 插件，当 KWR 插件创建后就可以使用 KSH 功能。
KSH 数据存储结构和使用方式和 Oracle ASH 非常相似，熟悉 Oracle 的朋友上手并没有太大的难度。KSH 的内存 RingBuf 数据可以通过 perf.session_history 视图查看，保存于数据库的历史数据可以通过 perf.ksh_history 进行查看，也可以通过 perf.ksh_report() 函数生成在线报告。
SELECT * FROM perf.ksh_report({start_ts}, {duration}, {slot_width}, {format});
当然，根据 Oracle ASH 的使用经验，直接查看 KSH 报告的场景并不多，更多的是分析 KSH 视图中保存的数据，对 SQL 执行情况进行详细的查看和分析。
写在最后
性能分析是数据库运维必不可少的工作，本篇介绍的几个工具，基本覆盖了数据库性能分析的大多数场景，值得大家好好学习和研究。
对于熟悉 Oracle 的朋友可能会发现，这些工具会有似曾相识的感觉。KWR 对应 Oracle 的 AWR，KSH 对应 Oracle ASH，有 Oracle 基础的朋友上手这些工具并没有什么难度。不过对于等待事件，其命名和 Oracle 的差异相对较大，而且两种数据库的底层实现逻辑也有较大的差别，因此对于底层的知识需要有更深入的了解。好在数据库底层原理终究是相通的，当你深入了解了一种数据库之后，学习和理解其他的数据库会更加轻松，这大概是那些 Oracler 们最大的优势吧！
