阿里云国际 DAS Performance Insight：SQL 性能定位与优化验证
数据库变慢时，CPU 升高只是现象，不一定是根因。真正需要回答的是：哪些 SQL 在消耗资源、执行次数是否突增、扫描行数是否异常、变更前后负载如何变化。阿里云国际数据库自治服务 DAS 的 Performance Insight 会聚合 SQL 执行信息，帮助运维人员从工作负载结构定位瓶颈，但诊断结果仍需结合执行计划、业务语义与变更记录判断。
Performance Insight 能解决什么问题
阿里云国际官方文档说明，Performance Insight 可基于 MySQL Performance Schema 等数据分析 SQL 工作负载，按 SQL ID 聚合同类语句，并展示资源使用、执行次数、扫描行数和执行耗时等指标。
它适合处理以下问题：
- 数据库负载突然升高，不清楚由哪些 SQL 引起；
- 某个接口变慢，需要定位对应查询模式；
- 发布后希望比较变更前后的 SQL 负载；
- 需要发现执行频繁、扫描量大或耗时异常的语句；
- 计划优化索引，但需要先找到影响最大的查询。
它不是“自动修复数据库”的工具。优化建议可能受到数据分布、并发、缓存和业务约束影响，不能未经验证直接应用到生产环境。
启用前先确认适用范围
不同数据库引擎、版本、地域和 DAS 版本支持的功能可能不同。官方资料中，基于 Performance Schema 的新版本主要面向受支持的 RDS MySQL、PolarDB for MySQL 等实例。进入控制台后，应先核对目标实例是否出现 Performance Insight 入口，以及启用所需条件。
启用 Performance Schema 或相关采集能力可能改变监控数据来源。生产环境应在变更窗口评估影响，记录原参数，并按官方提示操作。不要为了获取更多指标直接修改不理解的数据库参数。
还应确认数据访问权限。SQL 样本可能包含业务字段或敏感信息，DAS 控制台权限应只授予需要诊断的角色，导出的报告和截图也应脱敏。
用四步法定位性能瓶颈
第一步：确定问题时间窗口
先从业务告警、应用日志和用户反馈确定开始时间、持续时间与受影响功能。时间范围过大容易把日常负载与异常混在一起；过小又可能遗漏触发阶段。
同时记录发布、索引变更、数据导入、定时任务和流量变化。没有时间线，SQL 排名只能告诉你“谁消耗多”，无法证明“谁导致故障”。
第二步：观察整体负载构成
在 Performance Insight 中查看选定时段的负载趋势，关注执行次数、耗时、扫描行数和资源使用的变化。把异常窗口与正常基线比较，判断问题来自单条重 SQL、短时间高频请求，还是整体并发增长。
不要只看平均值。某条 SQL 平均耗时不高，但执行次数突然增加，也可能成为主要负载来源；另一条 SQL 执行很少，却可能因锁等待拖慢关键事务。
第三步：下钻到 SQL ID
按 SQL ID 查看趋势和样本，确认语句结构、表、过滤条件和执行频率。重点识别：
- 未使用有效过滤条件的大范围扫描；
- 缺少索引或索引选择不当；
- 重复调用导致的高频查询；
- 排序、分组或连接造成的大量临时操作；
- 参数差异导致执行计划变化；
- 在事务中长时间持锁的语句。
SQL 样本可能经过归一化，不能只依据展示文本修改代码。应回到应用追踪和数据库日志，找到真实调用链。
第四步：验证优化而非直接上线
可能的优化包括改写查询、增加或调整索引、减少重复请求、分批处理、限制异常 SQL 或调整应用缓存。每项修改都应在接近生产数据分布的环境验证。
验证至少包括执行计划、响应时间、扫描行数、写入开销和并发影响。新增索引可能加快读取，却增加写入成本和存储占用；SQL 限流可能保护数据库，却让上游请求排队。应同时观察应用与数据库。
如何比较变更前后效果
选择相近业务周期作为基线，避免把工作日与低峰时段直接比较。记录相同 SQL ID 的执行次数、平均与高分位耗时、扫描行数和资源占比，并结合业务吞吐量归一化。
如果优化后单次耗时下降，但调用次数大幅增长，总资源消耗仍可能上升。反之，CPU 没明显变化，但锁等待或关键接口延迟改善，也可能说明优化有效。
上线应采用小流量或分批方式，并保留回滚脚本。涉及索引删除、参数修改或 SQL 限流时，先确认回退路径，不在故障期间同时执行多项不可区分的变更。
API 与自动化使用边界
阿里云国际提供 GetPfsSqlSummaries 等 API，用于按实例和 SQL ID 查询 Performance Insight 聚合数据。自动化可以生成趋势报告或发现异常 SQL，但不应自动执行删索引、改参数或限流操作。
调用 API 时应：
- 使用 RAM 最小权限；
- 把密钥存放在受控密钥系统；
- 限制实例与地域范围；
- 对 SQL 文本和返回数据脱敏；
- 遵守接口频率与时间范围限制；
- 记录请求 ID 和自动化任务版本。
自动化告警应结合基线和业务流量，避免单一阈值产生大量误报。
常见错误判断
CPU 高并不必然意味着规格不足，低效 SQL 或突增调用可能是根因。扫描行数高也不一定错误，分析型任务可能本就需要全表处理，关键是它是否在正确时间、对正确副本执行。
另一个误区是把“无流量表或索引”直接视为可删除对象。统计窗口可能没有覆盖月末任务、灾备流程或低频报表。删除前应查询代码依赖、审计访问和业务负责人，并先在测试环境验证。
DAS 的建议也不是性能保证。数据库优化受数据量、分布、并发和硬件影响，任何预期收益都应通过真实压测与上线观察确认。
云管家建议把 Performance Insight 用作证据汇总工具：先建立时间线，再识别负载来源，随后在受控环境验证修改，最后持续比较业务指标。支持的引擎、指标、版本、费用和控制台入口以阿里云国际当前官方文档为准。
官方来源
- 阿里云国际 DAS：基于 Performance Schema 的 Performance Insight
https://www.alibabacloud.com/help/en/das/user-guide/performance-insight-8 - 阿里云国际 DAS：Performance Insight 工作负载分析
https://www.alibabacloud.com/help/en/das/user-guide/performance-insight-6 - 阿里云国际 DAS：Performance Insight 说明
https://www.alibabacloud.com/help/en/das/user-guide/performance-insight-9/ - 阿里云国际 DAS：GetPfsSqlSummaries API
https://www.alibabacloud.com/help/en/das/developer-reference/api-das-2020-01-16-getpfssqlsummaries
