作者：Digital Observer（施嘉伟）
Oracle  ACE Pro: Database
PostgreSQL  ACE Partner
11年数据库行业经验，现主要从事数据库服务工作
拥有Oracle  OCM、DB2 10.1 Fundamentals、MySQL 8.0 OCP、WebLogic 12c OCA、KCP、PCTP、PCSD、 PGCM、OCI、PolarDB技术专家、达梦师资认证、数据安全咨询高级等认证
ITPUB认证专家、PolarDB开源社区技术顾问、HaloDB技术顾问、TiDB社区技术布道师、青学会MOP技术社区专家顾问、国内某高校企业实践指导教师
公众号：Digital Observer；CSDN：施嘉伟；ITPUB：sjw1933；墨天轮：Digital Observer；PGFans：施嘉伟。

背景分析

在数据库系统的运维过程中，SQL 执行效率直接关系到系统性能表现。Kingbase 作为国产数据库中较为成熟的一员，基于 PostgreSQL 内核，具备丰富的可观测性和扩展能力。然而，实际项目中慢 SQL 的问题仍频繁出现，其根本原因既可能源自 SQL 语句本身写法不当，也可能涉及到索引缺失、统计信息不全、表数据膨胀、锁竞争或数据库参数配置不合理等多方面。

由于许多使用者是从 Oracle、MySQL 等数据库转向 Kingbase，对于 PostgreSQL 系体系的性能诊断工具与调优手段了解不深，导致问题一旦发生，排查成本高、效率低。因此，建立一套规范化的慢 SQL 分析路径显得尤为重要。本文将从实际运维角度出发，梳理 Kingbase 环境中定位和优化慢 SQL 的关键步骤与方法。

第一部分 慢SQL分析步骤

1.1 获取SQL

慢 SQL 的来源一般包括以下几种场景：

• 慢SQL语句监控告警：通过监控系统（如 Zabbix、Prometheus + Grafana）配置数据库响应时间告警阈值，实现第一时间告警。
• 数据库巡检发现异常SQL：定期巡检系统负载、I/O 压力、锁等待情况，通过  pg_stat_statements 查看执行耗时长、调用频繁的 SQL。
• 客户反馈SQL慢：前端页面响应慢、接口超时等业务现象，通常背后都伴随着数据库层的慢 SQL，需要根据用户操作时间段反查数据库日志。

1.2 收集统计信息

在获取到问题 SQL 后，下一步需要尽可能收集相关上下文信息，为后续分析提供依据：

• 获取完整的SQL语句：确认变量是否绑定、参数是否固定。
• 收集表结构和索引信息：包括表字段、主键/唯一约束、是否存在合适的联合索引。
• 表与索引的大小统计：通过  pg_relation_size() 或  pg_total_relation_size() 获取表/索引的磁盘占用。
• 系统统计视图分析：如  pg_stat_all_tables、 pg_stat_all_indexes、 pg_statio_all_tables 等，查看表/索引的扫描次数、缓存命中率等。
• 系统资源监控：结合操作系统工具（如  top,  vmstat,  iostat,  sar）分析慢 SQL 执行期间的 CPU、内存、磁盘压力。
• 数据库配置参数：查看  work_mem、 shared_buffers、 effective_cache_size、 random_page_cost 等关键性能参数配置。

1.3 分析SQL慢的原因

常见慢 SQL 可分为以下三类：

• SQL 一直很慢：语法或索引设计问题，可能执行计划始终较差。
• SQL 偶尔慢：缓存命中、并发锁等待、统计信息不准、计划不稳定。
• SQL 长时间运行未结束：可能进入死循环或等待资源。

处理方式主要包括：

1. 使用 EXPLAIN / EXPLAIN ANALYZE 分析执行计划：

   • 关注是否走了全表扫描；
   • 是否用了合适的索引；
   • 是否存在 Hash Join/ Nested Loop 的高代价操作；
   • rows 预估是否与实际数据量偏差较大。

2. 分析等待事件：

   • 通过  pg_stat_activity 查看 SQL 的状态、执行时间；
   • 判断是否在等待锁、IO、buffer 或其他后台资源。

3. 查看锁等待：

   • 查询  pg_locks 与  pg_stat_activity 联表分析，识别阻塞链；
   • 使用  pg_blocking_pids() 查出阻塞源。

第二部分 如何获取SQL

2.1 PG扩展模块支持

1. 跟踪SQL模块： pg_stat_statements

该模块可收集所有执行过的 SQL 语句的执行频次、平均耗时、总耗时等，为热点 SQL 定位提供极大帮助。

配置方法（需重启数据库）：

shared_preload_libraries = 'pg_stat_statements'
track_io_timing = on
track_activity_query_size = 2048
pg_stat_statements.max = 10000
pg_stat_statements.track = all
pg_stat_statements.track_utility = off
pg_stat_statements.save = on

启用后可通过以下 SQL 查看耗时高的 SQL：

SELECT query, calls, total_time, mean_timeFROM pg_stat_statementsORDER BY total_time DESC LIMIT 10;

2. 慢SQL日志模块： auto_explain

该模块可自动记录超过阈值的 SQL 的执行计划，尤其在定位偶发慢 SQL 时极为有用。

全局配置（同样需重启）：

shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = 1000
auto_explain.log_analyze = true
auto_explain.log_verbose = true
auto_explain.log_buffers = true
auto_explain.log_nested_statements = true

临时会话调试配置：

LOAD 'auto_explain';SET auto_explain.log_min_duration = 0;SET auto_explain.log_analyze = true;

此方法适合在不方便修改全局参数时快速分析某些会话中的 SQL 行为。

2.2 PG原生命令

通过  pg_stat_activity 可查看当前所有活动会话及其 SQL 状态：

SELECT * FROM pg_stat_activity WHERE datid IS NOT NULL;

字段如  state,  query_start,  wait_event_type,  wait_event,  query 可用于判断 SQL 执行是否卡住或进入等待状态。

此外，启用 PostgreSQL 原生命令日志记录也是必要手段：

log_min_duration_statement = 1000    # 记录超过1秒的SQL
log_statement = 'ddl'               # 记录DDL语句

总结

Kingbase 在处理 SQL 性能问题时，借助 PostgreSQL 强大的可扩展能力，可以通过多角度、分层次的手段快速定位慢 SQL 问题根源。本文构建了从 发现、收集信息、诊断、验证优化效果的完整链路，实用性强，适用于开发测试与运维场景。

性能优化不是一次性的任务，而是一项持续不断的工程。建议企业在日常运维中建立慢 SQL 的归档分析制度，结合业务场景定期复盘典型慢 SQL 的优化过程，并构建企业内部的调优知识库，从而提升团队整体运维能力与系统稳定性。