# 数据库负载
<a name="USER_PerfInsights.Overview.ActiveSessions"></a>

*数据库负载（DB 负载）*衡量数据库中的会话活动级别。`DBLoad` 是 Performance Insights 中的关键指标，Performance Insights 每秒都会收集数据库负载。

**Topics**
+ [活动的会话](#USER_PerfInsights.Overview.ActiveSessions.active-sessions)
+ [平均活动会话数](#USER_PerfInsights.Overview.ActiveSessions.AAS)
+ [平均活动执行数](#USER_PerfInsights.Overview.ActiveSessions.AAE)
+ [尺寸](#USER_PerfInsights.Overview.ActiveSessions.dimensions)

## 活动的会话
<a name="USER_PerfInsights.Overview.ActiveSessions.active-sessions"></a>

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

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

## 平均活动会话数
<a name="USER_PerfInsights.Overview.ActiveSessions.AAS"></a>

*平均活动会话数（AAS）*是 Performance Insights 中 `DBLoad` 指标的单位。它衡量数据库上有多少个会话同时处于活动状态。

Performance Insights 每秒都会对并行运行查询的会话数进行采样。对于每个活动的会话，Performance Insights 都会收集以下数据：
+ SQL 语句
+ 会话状态（正在 CPU 上运行或正在等待）
+ Host
+ 运行 SQL 的用户

Performance Insights 通过以下方式计算 AAS：对于特定时间段内，将会话总数除以样本数。例如，下表显示了正在运行的查询的 5 个连续样本，其间隔为 1 秒。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

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

## 平均活动执行数
<a name="USER_PerfInsights.Overview.ActiveSessions.AAE"></a>

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

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.ActiveSessions.html)

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

## 尺寸
<a name="USER_PerfInsights.Overview.ActiveSessions.dimensions"></a>

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

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

**Topics**
+ [等待事件](#USER_PerfInsights.Overview.ActiveSessions.waits)
+ [主要 SQL](#USER_PerfInsights.Overview.ActiveSessions.top-sql)

有关 Aurora 引擎维度的完整列表，请参阅 [按维度切片的数据库负载](USER_PerfInsights.UsingDashboard.Components.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.dims)。

### 等待事件
<a name="USER_PerfInsights.Overview.ActiveSessions.waits"></a>

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

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

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

等待事件因数据库引擎而异：
+ 有关 Aurora MySQL 的最常见等待事件的列表，请参阅 [Aurora MySQL 等待事件](AuroraMySQL.Reference.Waitevents.md)。要了解如何使用这些等待事件进行优化，请参阅 [优化 Aurora MySQL](AuroraMySQL.Managing.Tuning.md)。
+ 有关所有 MySQL 等待事件的信息，请参阅 MySQL 文档中的[等待事件摘要表](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html)。
+ 有关 Aurora PostgreSQL 的最常见等待事件的列表，请参阅 [Amazon Aurora PostgreSQL 等待事件](AuroraPostgreSQL.Reference.Waitevents.md)。要了解如何使用这些等待事件进行优化，请参阅 [使用 Aurora PostgreSQL 的等待事件进行优化](AuroraPostgreSQL.Tuning.md)。
+ 有关所有 PostgreSQL 等待事件的信息，请参阅 PostgreSQL 文档中的[统计数据收集器 > 等待事件表](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE)。

### 主要 SQL
<a name="USER_PerfInsights.Overview.ActiveSessions.top-sql"></a>

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

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