Aurora MySQL 优化的基本概念 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Aurora MySQL 优化的基本概念

在优化 Aurora MySQL 数据库之前,请务必了解等待事件和线程状态及其发生的原因。同时,在使用 InnoDB 存储引擎时查看 Aurora MySQL 的基本内存和磁盘架构。有关有用的架构图,请参阅 MySQL 参考手册

Aurora MySQL 等待事件

等待事件表示会话正在等待的资源。例如,等待事件 io/socket/sql/client_connection 表示线程正在处理新连接。会话等待的典型资源包括以下内容:

  • 例如,当会话试图修改缓冲区时,对缓冲区的单线程访问

  • 当前被另一个会话锁定的行

  • 已读取一个数据文件

  • 已写入一个日志文件

例如,为了满足查询,会话可能会执行完整的表扫描。如果数据尚未在内存中,会话将等待磁盘输入/输出完成。当缓冲区读取到内存时,会话可能需要等待,因为其他会话正在访问相同的缓冲区。数据库使用预定义的等待事件记录等待。这些事件按类别进行分组。

等待事件本身并不显示性能问题。例如,如果请求的数据不在内存中,则必须从磁盘读取数据。如果一个会话锁定行以进行更新,则另一个会话将等待解锁该行,以便它可以更新该行。提交需要等待对日志文件的写入完成。等待是数据库正常运行不可或缺的组成部分。

大量等待事件通常显示性能问题。在这种情况下,您可以使用等待事件数据来确定会话将时间花费在哪里。例如,如果通常在几分钟内运行的报告现在运行了数小时,则可以确定对总等待时间贡献最大的等待事件。如果您能确定顶级等待事件的原因,您有时就可以进行更改来提高性能。例如,如果您的会话正在等待已被另一个会话锁定的行,则可以结束锁定会话。

Aurora MySQL 线程状态

常规线程状态指的是与常规查询处理相关联的 State 值。例如,线程状态 sending data 表示线程正在读取和筛选查询的行以确定正确的结果集。

您可以使用线程状态以类似于使用等待事件的方式来优化 Aurora MySQL。例如,频繁发生 sending data 通常表示查询没有使用索引。有关线程状态的更多信息,请参阅 MySQL 参考手册中的常规线程状态

使用性能详情时,以下条件之一为真:

  • 性能架构已开启 – Aurora MySQL 显示等待事件而不是线程状态。

  • 性能架构未开启 – Aurora MySQL 显示线程状态。

我们建议您配置性能架构以实现自动管理。性能架构提供了更多洞察和更好的工具来调查潜在的性能问题。有关更多信息,请参阅为 Aurora MySQL 上的 Performance Insights 启用 Performance Schema

Aurora MySQL 内存

在 Aurora MySQL 中,最重要的内存区域是缓冲池和日志缓冲区。

主题

缓冲池

缓冲池是 Aurora MySQL 在其中缓存表和索引数据的共享内存区域。查询可以直接从内存访问常用的数据,而无需从磁盘读取。

缓冲池的结构为页面链接列表。一个页面可以容纳多个行。Aurora MySQL 使用最近最少使用的 (LRU) 算法将页面从池中排除。

有关更多信息,请参阅《MySQL 参考手册》中的缓冲池

Aurora MySQL 进程

Aurora MySQL 使用的流程模型与 Aurora PostgreSQL 截然不同。

MySQL 服务器 (mysqld)

MySQL 服务器是一个名为 mysqld 的单个操作系统进程。MySQL 服务器不会产生额外的进程。因此,Aurora MySQL 数据库使用 mysqld 来执行其大部分工作。

当 MySQL 服务器启动时,它会侦听来自 MySQL 客户端的网络连接。当客户端连接到数据库时,mysqld 会打开一个线程。

Threads (线程)

连接管理器线程将每个客户端连接与专用线程关联。该线程管理身份验证、运行语句并将结果返回到客户端。必要时,连接管理器会创建新线程。

线程缓存是一组可用的线程。连接结束时,如果缓存未满,MySQL 会将线程返回到线程缓存。thread_cache_size 系统变量决定了线程缓存的大小。

线程池

线程池由许多线程组组成。每个组管理一组客户端连接。当客户端连接到数据库时,线程池将以循环方式将连接分配给线程组。线程池将连接和线程分开。连接和运行从这些连接接收到的语句的线程之间没有固定的关系。