[kingbase运维之奇怪的现象]

#[kingbase运维之奇怪的现象]
##奇怪的现象
某银行数据中心应用反馈，业务接口日志记录了很多执行慢的SQL，出现的时间是随机的，单独在数据库客户端工具执行会很快返回结果。根据之前的经验推断是业务代码传入的参数类型与数据库表结构字段定义类型不一致，发送了隐式类型转换计划未走索引导致执行慢。带着这个推断与业务开发进行交流了解，反馈是会存在类型不完全匹配的情况，但是之前不慢，最近变慢了。带着疑问去我们去收集一下信息，为此我们需要开启数据库慢日志和auto_explain功能，打印SQL执行计划。
##auto_explain 工具介绍
这里我们先介绍一下auto_explain这个插件。官方文档链接[link]
(https://www.postgresql.org/docs/current/auto-explain.html)

The auto_explain module provides a means for logging execution plans of slow statements automatically, without having to run EXPLAIN by hand. This is especially helpful for tracking down un-optimized queries in large applications

让我们再问一下憨憨的gpt，开启auto_explain是否会对数据库性能产生影响呢？
1

kingbase最新版本默认带auto_explain，只需要修改数据库配置文件，库里创建扩展即可。PostgreSQL默认不带此插件需要编译安装一下。

$ vi /../data/kingbase.conf
$文件添加参数如下：
shared_preload_libraries =  'auto_explain'
auto_explain.log_min_duration=1000
auto_explain.log_analyze=on
1
2
3
4
5

效果演示:

工具已经准备好，接下来就是生产环境数据库开启此参数。额 , 熟悉银行运维开发的工程师都知道银行生产变更最重要的是流程要规范，准备变更申请单、提交测试验证报告、仿真环境验证测试…接下来领导审批，才能在生产进行变更。
##分析慢的原因
工具已经有了，接下来让我们一起看一下这个奇怪的现象背后SQL到底是如何执行的。

生产环境开启了auto_explain插件，抓取了两个简单查询执行慢的SQL。


分析执行计划，两个简单的查询SQL表数据扫描耗时不多，耗时主要是在结果合并gather上。推断并行资源征用导致gather执行耗时，为了确切定位问题，和客户申请关闭备机的并行功能，再次收集日志确定简单查询SQL是否执行时间合理。

终于…推动客户在备机节点关闭了并行参数。通过监控一周发现备机日志未在出现简单SQL执行时间很长的SQL。
到此基本确认是数据库的并行参数导致，接下来分析需要使用perf工具抓取主库简单SQL执行慢的时候的火焰图了。