本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 查询工作负载调优
经过良好调优的工作负载将对您在实现高速增长的稳定解决方案方面大有帮助。如果您的工作负载没有得到很好的调优，无论您使用的 Amazon Aurora 集群有多强大，都将遇到瓶颈，从而降低性能并影响应用程序的用户体验。最佳做法是从一开始就有一个流程，帮助您识别和调优系统中有问题的查询。
## 跟踪和调优工作负载中有问题的查询
当遇到高速增长时，拥有经过良好调优的工作负载是成功的一半。要了解实时工作负载的性质和 Aurora 集群面临的性能问题，确保您的团队从写入器和读取器实例中收集有问题的查询。需要调优这些有问题的查询，以使您的工作负载以最佳状态运行。Amazon Aurora MySQL 兼容版为您提供了两种方法来实现此目的：
+ 性能详情
+ 慢速查询日志
**使用 Performance Insights**
Performance Insights 根据平均活动会话（AAS）来跟踪 Aurora 写入器或读取器实例上的负载。AAS 值是使用采样和等待 CPU 拾取查询工作负载并进行处理的活动会话数来计算的。Performance Insights 提供了一个图形界面，您可以在其中检查因等待活动会话而导致最高负载的 SQL 语句。
在上一个屏幕截图中，对存储过程 `my_sqrt` 的调用导致平均有 13.03 个会话等待处理其负载。合乎逻辑的下一步是调优该过程。您应该找出读取器和写入器中对各自实例造成负载的 SQL 语句，并对其进行调优以提高性能，直到 AAS 值下降并保持在 Performance Insights 的最大 vCPU 虚线以下。如果您的调优工作已达到极限，但仍看到 AAS 超过最大 vCPU 线，则可以选择更大的实例类来处理您的工作负载。如果不先尝试调优查询工作负载，就不要选择更大的实例，因为不断增长的流量将开始暴露工作负载中由错误查询造成的故障线。
**使用慢速查询日志并将其发布到 CloudWatch**
慢速查询日志是 MySQL 的原生功能，是对 Performance Insights 的补充。最佳做法是同时使用这两种方法，提前发现可能对您的实例造成严重破坏的有问题的查询。慢速查询日志会记录任何比动态变量 `long_query_time` 慢的查询。无需重启集群实例即可设置此变量。
为了在调优练习中提供灵活性和隔离性，请为写入器和读取器实例使用单独的参数组。如果您使用读写分离，这一点尤其重要。根据需要为集群实例中的 `long_query_time` 设置一个适当的限值。在调优负载时，您可以在 `long_query_time` 变量中设置激进的值，因为您可以将阈值设置为毫秒级。凭借高并发性和良好调优的工作负载，几乎所有查询都应该以毫秒为单位运行。
当您将 Amazon Aurora MySQL 兼容版设置为将慢速查询记录到文件中时，Aurora MySQL 兼容版会将慢速查询日志写入 Aurora MySQL 兼容版文件系统并保留 24 小时。要将慢速查询日志保留更长的时间以供分析，请将其发布到 Amazon CloudWatch。您还可以构建 CloudWatch控制面板来监控您的慢速查询。有关更多信息，请参阅博客文章[创建亚马逊 CloudWatch 控制面板来监控亚马逊 RDS 和 Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/creating-an-amazon-cloudwatch-dashboard-to-monitor-amazon-rds-and-amazon-aurora-mysql/)。除了分析您在亚马逊上的慢查询外 CloudWatch，您还可以使用 pt-query-digest [Percona](https://www.percona.com/doc/percona-toolkit/LATEST/pt-query-digest.html) Toolkit 中的工具来分析慢速查询日志。
您也可以选择自动执行下载和分析查询的过程，以提高团队的效率。您的团队应检查频繁运行和间隔较长的查询，并优先对其进行调优。目标是在慢速查询日志中记录很少的查询，随着您对工作负载的了解和调优，可以减少 `long_query_time`，使其更加激进。