查询调优指南

在发现工作负载中有问题的查询后，应对每个查询进行调优。使用以下调优指南使您的工作负载更高效地运行。

尽量减少扫描行数

尽管看起来很简单，但这是您在调优查询时可以使用的一条很好的建议。使用 EXPLAIN 语句，查看行列，了解优化程序在每个联接处扫描的行数。尝试通过创建最佳索引来减少扫描的行数，然后重新解释查询以确认您的工作。有关更多信息，请参阅 MySQL 文档。

如果您使用分区表，请务必使用启用分区修剪的 WHERE 子句来查询它们，这样优化程序就不必扫描每个分区。如果 WHERE 子句包含分区列的常量，优化程序就会知道要查找哪个分区，从而提高查询效率。

该建议的另一个方面是数据库的设计。查询中的表越少，查询速度就越快。如果可以对数据库设计进行去规范化，就可以让优化程序扫描更少的行，从而提高查询性能。

尽量减少临时表的使用和磁盘上的临时表

如果 Aurora MySQL 兼容版优化程序无法直接从索引中获得所需的查询结果，则会在内存中和磁盘上创建临时表。因此，调优的一个重要方面就是为您的工作负载提供正确的索引。但是，工作负载中可能存在不能仅依赖索引的查询，因此某些操作可能会在临时文件中执行。只要将这些保持在最低限度，并确保在磁盘上创建的表很少，就没问题。当临时表的大小太大而无法存储在内存中时，MySQL 就会创建磁盘表。MySQL 用来检查内部临时表大小的逻辑是两个变量值 tmp_table_size 和中较小的一个。 max-heap-table-size您可以根据工作负载将这些变量调整为最佳值，这样在无法阻止临时表的情况下，仅在极少数情况下将它们推送到磁盘。

避免文件排序

如果您的工作负载有大量的 ORDER BY 查询，处理这些查询的最佳方法是在表上使用正确的索引。确保多列索引设计良好，避免在文件中排序。如果未使用常量扫描前面的列，则无法对列进行排序（in、>、<、!= 和 BETWEEN 不允许对右侧的下一列进行排序）。在 MySQL 中进行排序的最佳方式是放置一个多列索引，该索引将包含查询中提供的常量值的列放置在连续结构中排序列的左侧。在迫不得已的情况下，如果不进行文件排序，您的查询就无法返回结果，请将排序移至应用程序。

避免在高并发下运行聚合查询

您的工作负载可能有少量聚合查询，以符合应用程序中的某些功能。这个用例需要非常小心。InnoDB 引擎专为适当的联机事务处理（OLTP）负载而设计，但即使是几个高并发的分组查询也会对 CPU 造成很大的负担，并会迅速降低集群的性能。要解决需要聚合结果集的用例，请将数据预聚合到随时可读的表中，这样就可以完全避免 group by 查询。

测试查询的并发性

调整单个查询时，请记住，在兼容 Aurora MySQL 的情况下，这些查询CPUs 在多个 v 上同时运行。在您的测试环境中，查询可能在几毫秒内运行一次。但这不是全部。务必在生产集群上使用预期的并发级别测试您的查询，并对其性能进行基准测试。只有当查询符合您的并发目标时，才将其发布到生产环境。确保在测试脚本中使用优化程序 hint sql_no_cache，以避免从缓存中获取结果。您可以使用 mysqlslap 等工具以并发方式执行测试，并对结果进行基准测试。