本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 資料庫負載
<a name="USER_PerfInsights.Overview.ActiveSessions"></a>

*資料庫負載 (資料庫負載)* 會測量資料庫中工作階段活動的層級。`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)* 是 `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 個工作階段處於作用中。

## 平均作用中執行數
<a name="USER_PerfInsights.Overview.ActiveSessions.AAE"></a>

每秒平均作用中執行數 (AAE) 與 AAS 相關。若要計算 AAE，績效詳情會將查詢的總執行時間除以時間間隔。下表顯示上表中同一個查詢的 AAE 計算。


| 經過時間 (秒) | 總執行時間 (秒) | AAE | 算式 | 
| --- | --- | --- | --- | 
| 60 | 120 | 2 | 120 執行秒 / 60 秒經過 | 
| 120 | 120 | 1 | 120 執行秒 / 120 秒經過 | 
| 180 | 380 | 2.11 | 380 執行秒/180 秒經過 | 
| 240 | 380 | 1.58  | 380 執行秒/240 秒經過 | 
| 300 | 600 | 2 | 600 執行秒 / 300 秒經過 | 

在大多數情況下，查詢的 AAS 和 AAE 大致相同。不過，由於計算的輸入是不同的資料來源，所以計算通常會略有不同。

## 維度
<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% 的資料庫負載。在此情況下，高負載可能表示查詢發生問題。

根據預設，績效詳情主控台會顯示造成資料庫負載的常用 SQL 查詢。主控台也會顯示每個陳述式的相關統計資料。若要診斷特定陳述式的效能問題，您可以檢查其執行計劃。