夜雨聆风还在为数据库慢、连接数高、复制延迟、表膨胀、参数看不懂而来回切控制台、翻日志、查 SQL 视图吗？
现在，面向 PolarDB PostgreSQL 版的 PolarDB AI 助手正在把这些高频运维动作变成一次自然语言对话、一次按钮巡检、一次上下文诊断。它不是简单的问答窗口，而是面向数据库运维场景构建的智能助手：基于大语言模型、专家知识库和 PolarDB PostgreSQL 的运行观测能力，把实例状态、资源趋势、Top SQL、等待事件、复制延迟、表健康、IO、存储、参数配置等信息组织成一条可追溯的诊断证据链。
图 1：PolarDB AI 助手在实例详情页中的入口展示图
在 PolarDB 控制台中，用户可以通过右侧对话框直接提问，也可以通过 @ 选择实例、通过 / 选择技能。用户围绕具体问题发起诊断后，AI 助手会组织现场证据、解释原因，并给出下一步决策建议。
01
核心能力速览：问答、诊断、巡检与感知
围绕 PostgreSQL 运维场景，PolarDB AI 助手把问答、诊断、巡检和感知组织到同一套交互里：
这些能力可以从不同的控制台上下文进入。图 2 展示实例级巡检入口：用户选择巡检项目和时间范围后，即可生成结构化健康报告。
图 2：实例详情页中的"AI 实例巡检"入口展示图
除了实例级巡检，助手也可以承接用户正在查看的对象。图 3 展示在慢 SQL 页面围绕当前慢 SQL 发起分析，让诊断直接延续页面中的查询上下文。
图 3：慢 SQL 页面通过"PolarDB AI 分析"唤起 AI 助手的展示图
无论从对话、巡检还是具体对象进入，AI 助手都会围绕实例状态、时间范围和问题类型组织分析。
02
从数据基座到智能诊断：Global AWR 支撑的证据链
AI 诊断首先依赖数据。没有持续、完整且具备时间上下文的运行数据，AI 只能依据通用知识给出方向性建议，难以还原实例现场，也无法验证判断是否成立。
PolarDB-PG Global AWR：逻辑实例级的数据基座
PolarDB-PG 的 Global AWR 以逻辑实例为观察对象，从集群全局视角汇聚实例内的多层运行信息：
覆盖读写节点（RW）、只读节点（RO）等计算节点； 覆盖 SQL、等待事件、连接、事务、表和索引等数据库内部状态； 覆盖共享存储相关的 IOPS、吞吐和延迟，以及主机资源和高可用事件信息； 通过逻辑实例、物理节点和节点角色等维度，将不同组件的数据关联到同一条时间线上。
相较于传统 AWR 以周期快照生成报告的分析方式，PolarDB-PG Global AWR 在 AWR 报告能力基础上进一步扩展了观察范围和时间粒度。关键指标可以细化到秒级，并覆盖集群全部 RW/RO 节点、性能数据和事件信息，使几分钟甚至几秒钟内发生的性能抖动、连接异常和高可用事件能够被保留下来。
Global AWR 因此不仅是一组监控指标，更是 AI 助手进行历史回溯和关联分析的数据基座：它记录"当时发生了什么"，为后续判断"为什么发生"提供可复核的数据。
基于 Global AWR 的 AI 诊断：从指标查询到证据链
在用户授权范围内，AI 助手能够把实例实时运行状态与 Global AWR 沉淀的历史数据放到同一个时间窗口里分析。诊断不再只是回答"当前指标是多少"，而是进一步追问：异常从什么时候开始、持续了多久，和哪些 SQL、等待事件、写入峰值、复制状态或对象变化有关。
这条时间线很重要。CPU 高、连接数打满、复制延迟、IO 抖动、Checkpoint 峰值、WAL 增长、临时文件暴涨，都可能在几分钟内出现变化；即使异常仍在持续，单看某一类指标也很难判断原因。实例变慢可能伴随热点 SQL 和 CPU 升高，也可能主要表现为锁等待、IO 等待或连接堆积；复制延迟则需要结合写入量、大事务、网络传输和节点回放能力判断。失效的复制 Slot 和持续增长的 WAL 更多反映保留与存储压力，长事务则可能带来锁持有和清理受阻，需要作为关联证据一起检查。
围绕这条证据链，AI 助手已经能够组合两类数据：
实时状态用于确认问题当前是否仍在发生，历史趋势则用于还原问题发生时的负载与变化。两类证据结合后，助手可以判断资源峰值与 Top SQL、等待事件、连接堆积或复制状态是否在同一时间出现，避免用当前快照替代历史结论。
例如，针对 CPU 异常，助手可以回看目标时间窗口内的 CPU、IO、AAS、Top SQL 和等待事件；针对复制延迟，可以对照当前节点状态与历史延迟趋势；针对 IO 问题，则可以进一步区分 read、write 和 fsync 毛刺。用户最终看到的是一段可解释的运行过程：问题何时出现、哪些现象同时发生，以及后续应该怎样验证。
图 4 展示助手如何对照实时累计统计与 GAWR 历史窗口，识别目标时段内资源消耗突出的 SQL。Top SQL 只能说明"谁消耗得多"，还不能直接说明"为什么慢"。
图 4：SQL 性能诊断中的实时 Top SQL 与历史窗口对比展示图
找到资源消耗突出的 SQL 后，助手还会继续回答"它为什么慢"。如图 5 所示，诊断会把 SQL 与等待事件、AAS 和执行计划摘要关联起来，判断问题更接近锁等待、IO、CPU 计算，还是访问路径不合理，并给出相应的优化和复核方向。
图 5：SQL 性能诊断中的等待事件分析与执行计划摘要展示图
03
典型场景一：性能巡检，不止看 CPU 曲线
当用户在巡检入口选择"集群性能"并指定时间范围后，助手会先完成节点级资源检查。如图 6 所示，回答按照读写节点、只读节点和备节点分别给出 CPU、内存、连接数和 IOPS 使用情况，帮助用户快速判断风险出现在哪类资源、哪个节点。
图 6：集群性能巡检中的节点资源使用率展示图
资源指标回答"水位是否异常"，数据面分析则继续回答"负载来自哪里"。如图 7 所示，巡检会补充 GAWR 历史趋势、Top SQL 和等待事件：资源正常时用于确认运行趋势是否稳定，资源超阈值时则用于定位可能的 SQL、锁、IO 或会话压力。
图 7：集群性能巡检中的 GAWR 历史趋势、Top SQL 和等待事件分析展示图
在这些证据基础上，助手会综合实例规格、节点角色和时间趋势。对于超过阈值的资源项，会继续判断其是否与热点 SQL、锁等待、IO 抖动、连接堆积或业务负载突增相关。
一次性能巡检通常会回答几个问题：
CPU、内存、连接、IO 是否有明显风险； 异常是短时峰值还是持续趋势； 是否能定位到 Top SQL 或等待事件； 是否需要进一步做 SQL 性能诊断、锁诊断或 IO 诊断； 处理后应该如何复核。
这使巡检从"报数字"升级为"发现风险 + 解释原因 + 给出建议"。
04
典型场景二：锁等待事件，让阻塞关系更清楚
锁等待常常表现为业务 SQL 卡住、连接数堆积或事务迟迟不结束。只看到"有等待"还不够，排查时更需要知道：哪些会话在等待，等待的是哪类锁，是否存在持锁事务，影响范围是否还在扩大。
PolarDB AI 助手可以结合活跃会话、锁等待、等待事件和 SQL 信息，帮助用户把阻塞关系梳理清楚：
识别当前是否存在锁等待或会话阻塞； 区分等待会话、持锁会话和相关 SQL； 结合等待时长、事务时长和会话状态判断影响范围； 给出处理建议和复核方向，帮助用户在操作前评估风险。
当锁等待与 CPU、连接数、Top SQL 或历史等待事件同时出现时，助手还可以把这些信息放到同一时间窗口里看，判断它是一次短暂冲突，还是正在影响业务请求的持续阻塞。
当用户提出"当前是否存在锁等待或会话阻塞，请说明阻塞链和影响范围"时，助手会关联当前会话、锁对象、等待事件和 SQL。如图 8 所示，回答会明确谁在等待、谁在持锁，以及阻塞会话和被阻塞会话之间的关系。
图 8：锁等待诊断中的阻塞链可视化展示图
当前阻塞链回答"现在是谁阻塞了谁"，历史分析则回答"问题持续了多久"。如图 9 所示，助手会进一步回看历史锁等待趋势，判断它是已经恢复的短暂冲突，还是仍在影响业务请求的持续阻塞，并说明可能原因和复核方式。
图 9：锁等待诊断中的历史趋势、根因和影响范围展示图
05
典型场景三：表健康，让膨胀、索引和 XID 风险可解释
PostgreSQL 的表健康问题通常不是单点判断。
表膨胀可能与 Autovacuum、长事务、写入模式、统计信息和维护窗口有关；未使用索引可能浪费空间并增加写入成本；XID 年龄过高则可能引发回卷风险。过去，这些判断需要熟悉多个系统视图和 PG 内核概念。
PolarDB AI 助手可以将这些检查组织成一次表健康巡检：
覆盖业务库中的关键表对象； 检查 dead tuple、膨胀率和表大小； 识别统计周期内未使用的索引和高顺序扫描表； 检查数据库 XID 年龄和回卷风险； 结合长事务判断 Autovacuum 是否可能被阻塞； 输出风险等级、影响说明和维护建议。
当用户继续追问"为什么会膨胀""该不该 VACUUM""是否需要重建索引"时，助手可以进入表维护诊断路径，把证据链展开，而不是只给一句泛化建议。
如图 10 所示，表维护诊断并不是看到膨胀率后直接给出清理建议，而是结合 XID 年龄、Dead Tuple、Autovacuum 和长事务状态，区分回卷风险、空间膨胀和维护机制异常。
图 10：表维护诊断中的 XID 回卷风险和膨胀 Top 表展示图
如果用户进一步提出"请分析未使用索引、高顺序扫描和潜在缺失索引"，助手会进入索引优化诊断。如图 11 所示，回答会区分统计周期内未使用的索引和缺少有效访问路径的表，并结合对象大小、扫描次数和查询模式给出治理建议，避免仅凭一次统计直接删除或新增索引。
图 11：索引优化诊断中的未使用索引和高顺序扫描表展示图
06
典型场景四：复制、IO 与存储，把历史趋势带进诊断
很多 PG 运维问题必须放到时间线上看。
复制延迟不能只看当前延迟值，还要结合延迟趋势、WAL 状态、Slot 状态和长事务一起判断；IO 问题要结合 Buffer Cache、Checkpoint、读写延迟、fsync 抖动和 IOPS 趋势；存储风险则要拆解数据目录、WAL、日志、临时文件、复制 Slot 保留和对象级空间浪费。
基于 Global AWR 历史数据，PolarDB AI 助手可以回答更接近真实排障的问题：
"主从延迟是刚刚突发，还是过去一天持续升高？" "IO 延迟毛刺集中在 read、write 还是 fsync？" "WAL 增长是否和某个时间段的写入峰值相关？" "最近有没有 OOM、FATAL、PANIC 等异常事件？" "数据库活动模式是否发生变化，比如临时文件、死锁、CRUD 量突然变化？"
这些问题如果缺少历史趋势和多维证据，很难把现场串起来；结合 GAWR 历史趋势后，AI 助手能把问题放回发生的时间窗口里解释。如图 12 所示，复制诊断会区分 RO 与 Standby，并把当前复制状态与历史延迟趋势放在一起，判断延迟是瞬时波动还是持续累积。
图 12：复制延迟诊断中的 RO 与 Standby 延迟趋势展示图
复制链路正常并不代表实例不存在性能问题。图 13 进一步从 IO 角度展示 read、write 和 fsync 的延迟分布，用于识别延迟究竟来自读取、写入还是落盘阶段。
图 13：IO 性能诊断中的 read/write/fsync 延迟分布和节点 IO 对比展示图
对于容量与空间浪费问题，用户可以发起"存储健康"巡检。如图 14 所示，回答会把存储使用率、WAL 增长、复制 Slot、表膨胀和未使用索引放在同一份结果中，从实例容量一直检查到数据库对象。
图 14：存储健康巡检中的空间、WAL、复制 Slot、表膨胀和未使用索引展示图
07
参数解释：把"看不懂参数"变成"知道能不能改"
数据库参数往往是用户最容易犹豫的地方：参数描述简短，影响范围复杂，有些需要重启，有些会影响性能，有些只适合临时诊断窗口开启。
在 PolarDB 控制台参数页，AI 助手可以提供"参数释义"和"参数修改建议"：
解释参数控制的行为； 说明当前值的实际影响； 标注是否需要重启； 给出生产环境风险提示； 结合实例运行情况给出调整建议； 对高风险变更提示先在测试环境验证或安排维护窗口。
例如 auto_explain.log_analyze 这类参数，开启后可以记录更完整的执行计划信息，但也可能带来额外 CPU 和 I/O 开销。AI 助手会把"为什么有用"和"为什么危险"一起讲清楚，帮助用户在改参数前完成风险评估。图 15 展示参数释义如何结合参数语义、当前值和生效方式，帮助用户先理解"这个参数控制什么"。
图 15：参数页中对 auto_explain.log_analyze 进行参数释义的展示图
理解参数之后，用户还需要判断"现在能不能改"。图 16 展示保存变更前的修改建议和风险提示，把参数解释进一步转化为变更决策参考。
图 16：参数保存前的 AI 参数修改建议展示图
08
安全边界：授权可见、只读诊断、用户决策
数据库 AI 助手必须先让用户信任。
PolarDB AI 助手只会在用户授权范围内访问相关资源。为了提供准确的诊断和问答服务，助手会使用必要的集群元数据、性能监控指标、日志文件以及用户在对话框中输入的问题。
在数据面诊断上，相关能力遵循只读、安全、最小权限原则：
仅在用户授权范围内访问实例； 仅允许 SELECT、SHOW、EXPLAIN 等只读诊断动作； 不执行 DDL 或 DML； 不直接修改集群配置； 查询历史和集群数据遵守阿里云隐私政策及相关服务约定； 涉及参数调整、终止会话、索引创建、表维护等操作时，只提供建议、风险说明和复核步骤，由用户或 DBA 确认后执行。
这意味着 AI 助手可以帮助用户更快看清现场，但不会替用户绕过变更流程。它增强的是人的判断，而不是替代人的责任。如图 17 所示，数据面诊断工具在启用前会展示能力范围和授权说明，帮助用户明确 AI 助手会读取哪些诊断信息。
图 17：数据面诊断工具启用前的授权说明展示图
09
内部实践：Global AWR 支撑的值班告警闭环
这套能力已经应用到 PolarDB-PG 内部值班场景中。过去，Grafana 产生告警后，需要值班同学进入多个监控页面，围绕告警时间综合比对实例资源、数据库状态、异常事件及前后变化，才能判断告警原因和影响范围，再将分析结果整理到值班日报中。对于持续或重复告警，还需要反复确认状态是否变化、问题是否已经处理，整个过程既耗时，也依赖值班同学的分析经验。
现在，Grafana 仍然负责发现异常，值班助手则负责告警后的自动化巡检和初步诊断：
轮询告警：定时检查当前 firing 告警，区分新增告警和遗留告警； 关联现场：根据实例和告警时间，关联 Global AWR 中的资源趋势、数据库状态和异常事件； 对比变化：对比上一轮结果，判断告警已经恢复、持续存在，还是出现了新的变化； 沉淀结果：将诊断结论自动写入值班日报，减少人工整理和重复录入，让值班同学聚焦需要进一步确认和处置的事项。
例如，对于一次手动切换失败告警，助手会通过 Global AWR 还原同一实例当天多次切换的时间线，识别失败后的重试结果，并提示值班同学确认是否属于计划内操作。如图 18 左侧所示，分析结果会连同新增告警、遗留告警和建议确认项一起写入值班日报。对于 Core Dump、长事务、非活跃复制槽或实例进程退出等告警，助手也会持续跟踪其状态，避免恢复告警和遗留问题被重复处理或遗漏。如图 18 右侧所示，每轮巡检还会汇总新增与遗留告警、较上轮变化和需要人工介入的事项。AI 助手完成的是信息归集、证据关联和初步研判；涉及根因确认、业务影响判断及高风险处置时，仍由值班同学作出最终决策。
图 18：值班助手巡检告警闭环效果。左：基于 Global AWR 还原告警时间线并写入日报；右：汇总新增与遗留告警、状态变化及人工介入事项。
这使内部值班从"逐条打开告警、人工拼接现场"，逐步转向"AI 先完成巡检和证据整理，值班同学聚焦确认和处置"。Global AWR 提供可回溯的数据现场，AI 助手则把这些数据转化为持续运行的值班诊断流程。
10
从建议到可验证的判断
当诊断能够同时利用实时状态和历史趋势，用户看到的不再只是一条孤立建议，而是一段可复核的判断过程：异常何时出现、哪些指标同时变化、问题更接近突发抖动还是持续压力、应该采取什么处理方向，以及处理后如何确认效果。
这类输出更接近 DBA 的真实排查方式：先看现场，再串证据，最后给建议。PolarDB AI 助手正在把这套专家经验沉淀到产品流程里，将控制台信息、实时运行状态、GAWR 历史现场和诊断建议组织到同一条证据链中。
过去，排查一个问题可能需要在监控、日志、SQL、文档和工单之间来回跳转；现在，用户可以用一句自然语言发起诊断，也可以点击按钮完成实例巡检，还可以把巡检固化为周期任务。
从"翻指标"到"看证据"，从"事后排障"到"持续巡检"，PolarDB AI 助手正在让 PostgreSQL 运维变得更可解释、更可复用，也更接近真实 DBA 的工作方式。