数据库负载
数据库负载（DB 负载）衡量数据库中的会话活动级别。性能详情的关键指标是 DBLoad，每秒收集一次。
活动会话
数据库会话表示的是应用程序与关系数据库的对话。活动的会话 是已将作业提交到数据库引擎并且正在等待响应的连接。
当会话在 CPU 上运行或等待资源变为可用以便继续执行时，该会话即处于活动状态。例如，活动的会话可能会等待页面（或块）读入内存中，然后占用 CPU 以从页面读取数据。
平均活动会话数
平均活动会话数 (AAS)是性能详情中 DBLoad 指标的单位。它衡量数据库上有多少个会话同时处于活动状态。
性能详情每秒都会对并行运行查询的会话数进行采样。对于每个活动的会话，性能详情都会收集以下数据：
-
SQL 语句
-
会话状态（正在 CPU 上运行或正在等待）
-
主机
-
运行 SQL 的用户
性能详情通过以下方式计算 AAS：对于特定时间段内，将会话总数除以样本数。例如，下表显示了正在运行的查询的 5 个连续样本，其间隔为 1 秒。
| 示例 | 运行查询的会话数 | AAS | 计算 |
|---|---|---|---|
| 1 | 2 | 2 | 总计 2 个会话/1 个样本 |
| 2 | 0 | 1 | 总计 2 个会话/2 个样本 |
| 3 | 4 | 2 | 总计 6 个会话/3 个样本 |
| 4 | 0 | 1.5 | 总计 6 个会话/4 个样本 |
| 5 | 4 | 2 | 总计 10 个会话/5 个样本 |
在前面的示例中，该时间间隔的数据库负载为 2 AAS。这一测量结果表明，在采集 5 个样本的时间间隔内，在任何给定时间，平均有 2 个会话处于活动状态。
数据库负载可以类比成仓库中的工人活动。假设仓库雇用了 100 名工人。如果收到 1 个订单，则会有 1 名工人配送订单，而 99 名工人闲置。如果收到 100 个订单，则所有 100 名工人将同时配送订单。如果经理每 15 分钟记下有多少工人同时处于活动状态，在一天结束时将这些数字相加，然后将总数除以样本数，则经理可计算出任何给定时间处于活动状态的平均工人人数。如果昨天平均为 50 名工人而今天为 75 名工人，那么仓库的平均活动水平提升了。同样，数据库负载会随着数据库会话活动增加而增加。
平均活动执行数
每秒的平均活动执行数 (AAE) 与平均活动会话数相关。为了计算平均活动执行数，性能详情使用查询的总执行时间除以时间间隔。下表显示了上表中同一查询的平均活动执行数计算。
| 运行时间（秒） | 总执行时间（秒） | AAE | 计算 |
|---|---|---|---|
| 60 | 120 | 2 | 120 秒执行时间/60 秒运行时间 |
| 120 | 120 | 1 | 120 秒执行时间/120 秒运行时间 |
| 180 | 380 | 2.1.1 | 380 秒执行时间/180 秒运行时间 |
| 240 | 380 | 1.58 | 380 秒执行时间/240 秒运行时间 |
| 300 | 600 | 2 | 600 秒执行时间/300 秒运行时间 |
在大多数情况下，查询的平均活动会话数和平均活动执行数大致相同。但是，由于计算所用的数据是不同的数据源，因此计算通常略有不同。
维度
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 文档中的等待类型
。
注意
对于 Oracle，后台进程有时在没有关联的 SQL 语句的情况下工作。在这些情况下，Performance Insights 报告以冒号连接的后台进程类型以及与该后台进程关联的等待类。后台进程类型包括 LGWR、ARC0、PMON 等。
例如，在存档程序执行 I/O 时，它的 Performance Insights 报告类似于 ARC1:System I/O。有时，还会缺少后台进程类型，而 Performance Insights 仅报告等待类，例如 :System
I/O。
主要 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）选项卡重点关注问题最严重的查询计划。
注意
Performance Insights 不会捕获文本超过最大可收集查询文本限制的查询计划。有关更多信息，请参阅在 Performance Insights 控制面板中访问更多 SQL 文本。
执行计划的保留期与性能详情数据的保留期相同。免费套餐中的保留设置为 Default (7 days) [原定设置（7 天）]。要将性能数据保留更长时间，请指定 1–24 个月。有关保留期的更多信息，请参阅性能详情的定价和数据留存。
摘要查询
Top SQL（主要 SQL）选项卡默认显示摘要查询。摘要查询本身没有计划，但所有使用文本值的查询都有计划。例如，摘要查询可能包括文本 WHERE `email`=?。摘要可能包含两个查询，一个带有文本 WHERE email=user1@example.com，另一个带有 WHERE
email=user2@example.com。每个文本查询都可能包括多个计划。
如果选择摘要查询，控制台将显示所选摘要的子语句的所有计划。因此，无需浏览所有子语句即可查看计划。计划可能不会显示在前 10 个子语句的列表中。控制台会显示已收集计划的所有子查询计划，无论查询是否在前 10 列表中。