数据库负载

数据库负载（DB 负载） 衡量数据库中的会话活动级别。性能详情的关键指标是 DBLoad ，每秒收集一次。

数据库会话 表示的是应用程序与关系数据库的对话。 活动的会话 是已将作业提交到数据库引擎并且正在等待响应的连接。

当会话在 CPU 上运行或等待资源变为可用以便继续执行时，该会话即处于活动状态。例如，活动的会话可能会等待页面（或块）读入内存中，然后占用 CPU 以从页面读取数据。

平均活动会话数

平均活动会话数 (AAS) 是性能详情中 DBLoad 指标的单位。它衡量数据库上有多少个会话同时处于活动状态。

性能详情每秒都会对并行运行查询的会话数进行采样。对于每个活动的会话，性能详情都会收集以下数据：

在前面的示例中，该时间间隔的数据库负载为 2 AAS。这一测量结果表明，在采集 5 个样本的时间间隔内，在任何给定时间，平均有 2 个会话处于活动状态。

数据库负载可以类比成仓库中的工人活动。假设仓库雇用了 100 名工人。如果收到 1 个订单，则会有 1 名工人配送订单，而 99 名工人闲置。如果收到 100 个订单，则所有 100 名工人将同时配送订单。如果经理每 15 分钟记下有多少工人同时处于活动状态，在一天结束时将这些数字相加，然后将总数除以样本数，则经理可计算出任何给定时间处于活动状态的平均工人人数。如果昨天平均为 50 名工人而今天为 75 名工人，那么仓库的平均活动水平提升了。同样，数据库负载会随着数据库会话活动增加而增加。

平均活动执行数

每秒的 平均活动执行数 (AAE) 与平均活动会话数相关。为了计算平均活动执行数，性能详情使用查询的总执行时间除以时间间隔。下表显示了上表中同一查询的平均活动执行数计算。

在大多数情况下，查询的平均活动会话数和平均活动执行数大致相同。但是，由于计算所用的数据是不同的数据源，因此计算通常略有不同。

db.load 指标不同于其他时间序列指标，因为您可以将它分为称为 维度 的子组件。您可以将维度视为 DBLoad 指标的不同特征的“切片依据”类别。

诊断性能问题时，以下维度通常最有用：

有关 Amazon RDS 引擎维度的完整列表，请参阅 按维度切片的数据库负载 。

等待事件 会导致 SQL 语句等待特定事件发生，然后才能继续运行。等待事件是数据库负载的一个重要维度（或称类别），因为它们指示了工作受阻的位置。

每个活动的会话要么会在 CPU 上运行，要么仍在等待。例如，在搜索内存寻找缓冲区、执行计算或运行过程代码时，会话都会占用 CPU。当会话不占用 CPU 时，它们可能正在等待内存缓冲区变为空闲、等待要读取的数据文件或等待将要写入的日志。会话等待资源的时间越长，它在 CPU 上运行的时间就越少。

当您优化数据库时，经常尝试找出会话正在等待的资源。例如，两三个等待事件可能会占据数据库负载的 90％。这一测量结果表明，平均而言，活动会话花费了大部分时间用于等待少量资源。如果您能找出导致这些等待的原因，就可以尝试提出解决方案了。

想想仓库工人的类比。收到了一个订单，内容是一本书。工人在配送订单时可能会出现延迟。例如，其他的工人目前可能正在补货架，因此手推车可能已被占用。或者用于输入订单状态的系统可能运行缓慢。工人等待的时间越长，完成订单所需的时间就越长。等待是仓库工作流程中常见的现象，但是如果等待时间过长，生产力就会降低。同样，重复或冗长的会话等待可能会降低数据库性能。有关更多信息，请参阅《 Amazon Aurora 用户指南 》中的 为 Aurora PostgreSQL 优化等待事件 和 为 Aurora MySQL 优化等待事件 。

等待事件因数据库引擎而异：

有关所有 MariaDB 和 MySQL 等待事件的信息，请参阅 MySQL 文档中的 等待事件摘要表 。

有关所有 PostgreSQL 等待事件的信息，请参阅 PostgreSQL 文档中的 统计数据收集器 > 等待事件表 。

有关所有 Oracle 等待事件的信息，请参阅 Oracle 文档中的 等待事件说明 。

有关所有 SQL Server 等待事件的信息，请参阅 SQL Server 文档中的 等待类型 。

主要 SQL

等待事件显示运行中的瓶颈，而主要 SQL 则显示哪些查询对数据库负载的影响最大。例如，当前可能正在数据库上运行着许多查询，但某一个查询可能会占用 99% 的数据库负载。在这种情况下，高负载可能表示查询存在问题。

默认情况下，Performance Insights 控制台会显示导致数据库负载的主要 SQL 查询。控制台还显示每个语句的相关统计信息。要诊断特定语句的性能问题，可以检查其执行计划。

执行计划 ，也简称为 计划 ，是访问数据的一系列步骤。例如，连接表 t1 和 t2 的计划可能会循环访问 t1 中的所有行，并将每一行与 t2 中的行进行比较。在关系数据库中， 优化程序 是确定 SQL 查询最有效计划的内置代码。

对于 Oracle 数据库实例，Performance Insights 会自动收集执行计划。若要诊断 SQL 性能问题，请检查为高资源 Oracle SQL 查询捕获的计划。这些计划会显示 Oracle Database 如何解析和运行查询。

若要了解如何使用计划分析数据库负载，请参阅 使用 Performance Insights 控制面板分析 Oracle 执行计划 。

Performance Insights 每五分钟就会识别资源密集度最高的 Oracle 查询并捕获其计划。因此，无需手动收集和管理大量计划。相反，您可以使用 Top SQL （主要 SQL）选项卡重点关注问题最严重的查询计划。

执行计划的保留期与性能详情数据的保留期相同。 免费套餐中的保留设置为 Default (7 days) [原定设置（7 天）]。要将性能数据保留更长时间，请指定 1–24 个月。有关保留期的更多信息，请参阅 性能详情的定价和数据留存 。