摘要信创数据库上了 K8s慢 SQL 排查直接倒退三年业务报慢才知道有问题、登库查还要进 Pod、没有历史趋势、没法告警、排障全靠手敲 SQL。很多团队要么裸跑无监控要么硬套 MySQL 监控模板指标不对、采集失败、根本用不起来。本文基于政务、金融生产项目落地经验输出K8s 环境人大金仓 V9 / 达梦 DM9 全套慢 SQL 监控方案Sidecar 模式无侵入部署、Prometheus 自动发现采集、Grafana 可视化看板、慢 SQL 自动捕获、分级告警规则全覆盖。所有配置、SQL、看板均可直接复制照着做 1 小时就能搭完生产级慢 SQL 监控体系。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。所有配置均在 K8s 1.26 对应数据库企业版实测跑通生产可用。一、痛点直击K8s 国产数据库慢 SQL 为什么难监控 核心结论不是数据库没有监控能力是 K8s 场景下传统监控方案不好使加上国产数据库生态不完善导致很多团队裸跑。1.1 四大核心痛点排查效率低出问题要 kubectl exec 进 Pod手动敲 SQL 查没有历史记录事后无法回溯部署麻烦传统 Agent 方式不适合容器独立部署又要维护网络、端口K8s 漂移后还要改配置生态不完善MySQL 有成熟的 mysqld_exporter金仓、达梦的官方 exporter 要么没有、要么功能弱慢 SQL 指标要自己写告警缺失慢 SQL 突增没有告警等业务反馈过来故障已经扩大了1.2 我们要达到的效果✅ 不用进 PodGrafana 看板直接看所有慢 SQL✅ 有历史趋势能看什么时候开始慢、慢了多久✅ 自动告警慢 SQL 数量突增、TOP SQL 耗时异常第一时间通知✅ 无侵入部署不用改数据库镜像Sidecar 直接加✅ K8s 原生适配Pod 漂移、扩容自动发现不用改配置二、架构选型Sidecar 无侵入 云原生自动发现2.1 整体架构数据库PodStatefulSet ├─ 数据库主容器金仓/达梦 └─ Exporter Sidecar容器指标采集 ↓ 指标暴露 /metrics PrometheusServiceMonitor自动发现 ↓ Grafana可视化看板 Alertmanager分级告警2.2 为什么选 Sidecar 模式部署方式优点缺点推荐度Sidecar 同 Pod网络开销小、地址固定、随 Pod 自动部署、运维简单每个 Pod 多一个容器⭐⭐⭐⭐⭐独立 Deployment资源共享、集中管理网络配置复杂、漂移后地址变更⭐⭐⭐节点 Agent部署简单容器化场景适配差、权限不好控⭐⭐ 生产推荐 Sidecar和数据库同生命周期配置一次写进 StatefulSet永远跟着数据库走K8s 怎么漂移都不怕。2.3 Exporter 选型数据库推荐 Exporter原理人大金仓 V9postgres_exporter金仓兼容 PG 协议自定义 SQL 扩展慢 SQL 指标达梦 DM9dm_exporter / 自定义 JDBC exporter官方 exporter 自定义 SQL 采集慢 SQL、锁等待三、部署实战人大金仓 V9 监控全配置金仓兼容 PostgreSQL 协议用 postgres_exporter 自定义 SQL 就能完美适配重点是把系统视图从 pg_改成 sys_。3.1 第一步创建专用监控用户最小权限生产绝对不能用 system 账号做监控建专用只读用户-- 金仓V9 执行 CREATE USER monitor WITH PASSWORD Monitor2026; GRANT pg_monitor TO monitor; GRANT SELECT ON sys_stat_activity TO monitor; GRANT SELECT ON sys_stat_database TO monitor; GRANT SELECT ON sys_stat_bgwriter TO monitor;3.2 第二步自定义慢 SQL 采集配置创建 ConfigMap存放慢 SQL 采集规则这是监控的核心# kingbase-exporter-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: kingbase-exporter-queries namespace: kingbase data: queries.yaml: | slow_sql_count: query: | SELECT count(*) AS slow_sql_count FROM sys_stat_activity WHERE state ! idle AND now() - query_start interval 1s AND backend_type client backend; slow_sql_detail: query: | SELECT pid, usename, datname, state, now() - query_start AS duration, substring(query, 1, 200) AS sql_text FROM sys_stat_activity WHERE state ! idle AND now() - query_start interval 1s ORDER BY query_start ASC LIMIT 20; metrics: - pid: usage: LABEL description: 会话ID - usename: usage: LABEL description: 用户名 - duration: usage: GAUGE description: SQL执行时长秒数 db_hit_ratio: query: | SELECT datname, sum(blks_hit) * 100.0 / nullif(sum(blks_hit blks_read), 0) AS hit_ratio FROM sys_stat_database GROUP BY datname; metrics: - datname: usage: LABEL - hit_ratio: usage: GAUGE description: 缓存命中率3.3 第三步StatefulSet 追加 Sidecar 容器在原有金仓 StatefulSet 的containers里追加 exporter# 追加到 spec.template.spec.containers 下 - name: kingbase-exporter image: prometheuscommunity/postgres-exporter:v0.15.0 imagePullPolicy: IfNotPresent ports: - containerPort: 9187 name: metrics env: - name: DATA_SOURCE_URI value: localhost:54321/postgres?sslmodedisable - name: DATA_SOURCE_USER value: monitor - name: DATA_SOURCE_PASS valueFrom: secretKeyRef: name: kingbase-secret key: monitor_password - name: PG_EXPORTER_EXTEND_QUERY_PATH value: /etc/exporter/queries.yaml volumeMounts: - name: exporter-queries mountPath: /etc/exporter resources: requests: cpu: 0.1 memory: 128Mi limits: cpu: 0.5 memory: 512Mi # 追加到 volumes 下 - name: exporter-queries configMap: name: kingbase-exporter-queries3.4 第四步Metrics Service 暴露指标给 Prometheus 采集用apiVersion: v1 kind: Service metadata: name: kingbase-metrics namespace: kingbase labels: app: kingbase metrics: true spec: type: ClusterIP selector: app: kingbase ports: - port: 9187 targetPort: 9187 name: metrics四、部署实战达梦 DM9 监控全配置达梦用官方 dm_exporter 或通用 JDBC exporter核心是通过系统视图v$sessions、v$sql采集慢 SQL。4.1 第一步创建监控用户-- 达梦DM9 执行 CREATE USER monitor IDENTIFIED BY Monitor2026; GRANT SELECT ANY DICTIONARY TO monitor; GRANT SELECT ON v$sessions TO monitor; GRANT SELECT ON v$sql TO monitor; GRANT SELECT ON v$sysstat TO monitor;4.2 第二步自定义采集 SQL 配置# dmdb-exporter-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: dmdb-exporter-queries namespace: dmdb data: queries.yaml: | slow_sql_count: query: | SELECT count(*) AS slow_sql_count FROM v$sessions WHERE state ACTIVE AND sysdate - create_time 1.0 / 86400; slow_sql_detail: query: | SELECT sess_id, user_name, state, (sysdate - create_time) * 86400 AS duration_sec, substr(sql_text, 1, 200) AS sql_text FROM v$sessions WHERE state ACTIVE AND (sysdate - create_time) * 86400 1 ORDER BY create_time ASC LIMIT 20; cache_hit_ratio: query: | SELECT (1 - sum(phys_reads)/sum(logical_reads)) * 100 AS hit_ratio FROM v$bufferpool;4.3 第三步StatefulSet 追加 Sidecar推荐使用自定义 JDBC exporter 适配达梦# 追加到 spec.template.spec.containers 下 - name: dmdb-exporter image: bitnami/jmx-exporter:latest # 或专用dm_exporter镜像 imagePullPolicy: IfNotPresent ports: - containerPort: 9160 name: metrics env: - name: DB_URL value: jdbc:dm://localhost:5236 - name: DB_USER value: monitor - name: DB_PASSWORD valueFrom: secretKeyRef: name: dmdb-secret key: monitor_password - name: CONFIG_FILE value: /etc/exporter/queries.yaml volumeMounts: - name: exporter-queries mountPath: /etc/exporter resources: requests: cpu: 0.1 memory: 128Mi limits: cpu: 0.5 memory: 512Mi # volumes 追加 - name: exporter-queries configMap: name: dmdb-exporter-queries4.4 第四步Metrics ServiceapiVersion: v1 kind: Service metadata: name: dmdb-metrics namespace: dmdb labels: app: dmdb metrics: true spec: type: ClusterIP selector: app: dmdb ports: - port: 9160 targetPort: 9160 name: metrics五、Prometheus 采集与自动发现配置K8s 环境用 ServiceMonitor 自动发现不用手动写静态配置扩缩容、漂移自动适配。5.1 人大金仓 ServiceMonitorapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: kingbase-metrics namespace: monitoring spec: namespaceSelector: matchNames: - kingbase selector: matchLabels: metrics: true endpoints: - port: metrics interval: 15s scrapeTimeout: 10s path: /metrics5.2 达梦 ServiceMonitorapiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: dmdb-metrics namespace: monitoring spec: namespaceSelector: matchNames: - dmdb selector: matchLabels: metrics: true endpoints: - port: metrics interval: 15s scrapeTimeout: 10s 采集频率建议 15 秒既能捕捉慢 SQL 波动又不会给数据库造成太大压力。六、Grafana 可视化看板核心指标全覆盖6.1 看板核心面板设计表格面板区域核心指标作用概览区活跃连接数、缓存命中率、TPS、QPS一眼看数据库整体健康度慢 SQL 区慢 SQL 数量趋势、TOP10 慢 SQL 文本与耗时直接定位最慢的 SQL资源区CPU 使用率、内存使用率、IO 等待判断是资源问题还是 SQL 问题锁等待区锁等待数量、阻塞链快速判断是不是锁阻塞导致的慢表空间区数据盘、WAL 盘、归档盘使用率提前发现磁盘风险6.2 核心 PromQL 示例# 慢SQL数量 kingbase_slow_sql_count{namespacekingbase} # 缓存命中率 avg(kingbase_db_hit_ratio{namespacekingbase}) by (datname) # 活跃连接数 kingbase_connections_state{stateactive} # 达梦慢SQL数量 dmdb_slow_sql_count{namespacedmdb}6.3 看板落地建议按数据库实例分变量切换一套看板看所有实例慢 SQL 面板开启自动刷新5 秒刷新一次TOP SQL 面板显示完整 SQL 文本点击可查看执行计划链接七、慢 SQL 自动捕获与分级告警体系光看板不够还要主动告警别等业务反馈才知道出问题。7.1 三级告警规则告警级别触发条件通知对象响应时效一般告警慢 SQL 数量 5 且持续 5 分钟开发 DBA工作日处理严重告警慢 SQL 数量 20 且持续 2 分钟运维 DBA30 分钟内响应紧急告警活跃连接数 80% 且慢 SQL 突增 3 倍全组立即响应7.2 告警规则示例PrometheusRuleapiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: kingbase-slow-sql-rules namespace: monitoring spec: groups: - name: kingbase-slow-sql rules: - alert: KingbaseSlowSQLIncreasing expr: increase(kingbase_slow_sql_count[5m]) 10 for: 2m labels: severity: warning annotations: summary: 人大金仓慢SQL数量突增 description: 实例 {{ $labels.pod }} 慢SQL数量5分钟增长超过10条请及时排查 - alert: KingbaseConnectionsHigh expr: kingbase_connections_state{stateactive} 400 for: 1m labels: severity: critical annotations: summary: 人大金仓活跃连接数过高 description: 实例 {{ $labels.pod }} 活跃连接数超过400存在连接雪崩风险7.3 进阶慢 SQL 自动抓执行计划严重告警触发时自动执行脚本抓取对应 SQL 的执行计划附在告警里不用人工登库查Alertmanager 触发 webhook调用运维脚本进 Pod 抓取 SQL 执行计划、AWR 报告告警通知附带分析结果直接定位问题八、生产级避坑10 个监控落地常见坑⚠️坑 1用超级管理员账号做监控风险权限过大存在安全隐患等保不合规整改建专用只读监控用户只授予必要的系统视图权限⚠️坑 2采集频率太高把数据库拖慢风险每秒采集一次复杂查询 SQL 本身就慢反向影响业务整改15 秒采集间隔足够慢 SQL 视图查询要加 limit不要全表查⚠️坑 3金仓直接用 PG 原生 exporter 配置不改风险系统视图名不对采集失败或指标为空整改所有 pg_前缀视图改成 sys_对应金仓系统视图⚠️坑 4exporter 和数据库跨节点部署风险网络开销大Pod 漂移后地址变了采集断了整改Sidecar 同 Pod 部署localhost访问稳定无感知⚠️坑 5只监控数量不抓 SQL 文本风险只知道有慢 SQL不知道是哪条排障还要登库整改自定义 SQL 采集 TOP 慢 SQL 文本看板直接能看⚠️坑 6慢 SQL 阈值设太低风险100ms 就算慢 SQL告警风暴没人看整改业务场景设置合理阈值OLTP 系统 1 秒以上算慢 SQL⚠️坑 7没有历史数据无法对比风险不知道是一直慢还是突然变慢无法定位变更点整改Prometheus 至少保留 30 天历史数据支持周同比、日环比⚠️坑 8监控指标不打标签风险多实例分不清哪个库的问题整改所有指标带上 namespace、pod、实例名标签便于聚合筛选⚠️坑 9告警只发一次不升级风险告警被忽略故障扩大整改分级告警持续不解决自动升级严重告警电话通知⚠️坑 10只监控不治理风险看板再好看慢 SQL 一直摆在那没人优化整改建立每周慢 SQL 治理机制TOP SQL 定期优化九、常用排查 PromQL 与 SQL 速查9.1 PromQL 速查# 慢SQL数量趋势 rate(kingbase_slow_sql_count[5m]) # 缓存命中率 avg(kingbase_db_hit_ratio) by (pod) # 活跃连接数TOP5 topk(5, kingbase_connections_state{stateactive}) # 达梦慢SQL数量 dmdb_slow_sql_count{namespacedmdb}9.2 数据库排查 SQL 速查人大金仓查慢 SQLSELECT pid, usename, now() - query_start AS 执行时长, state, query FROM sys_stat_activity WHERE state ! idle ORDER BY query_start ASC;达梦查慢 SQLSELECT sess_id, user_name, (sysdate - create_time) * 86400 AS 执行时长秒, state, sql_text FROM v$sessions WHERE state ACTIVE ORDER BY create_time ASC;总结K8s 环境下国产数据库慢 SQL 监控不是简单装个 exporter 就完事要做到能看见、能告警、能回溯、能定位。Sidecar 模式无侵入部署、自定义 SQL 精准采集、Prometheus 自动发现、Grafana 可视化、分级告警联动整套体系跑起来慢 SQL 排查效率提升 10 倍以上。数据库监控不是为了好看板是为了故障早发现、快定位、少影响业务。把监控做扎实比出了事故再救火重要得多。政务选金仓金融选达梦MySQL 迁移选金仓Oracle 迁移选达梦。专栏推荐专注 SpringBoot3 人大金仓 达梦信创实战持续输出生产级部署、性能调优、监控运维、避坑指南干货关注不迷路。觉得文章有用的话欢迎点赞、收藏、关注三连后续更新更多信创数据库云原生运维的硬核内容。