本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
資料庫負載
資料庫負載 (DB 負載) 會測量資料庫中工作階段活動的層級。績效詳情中的關鍵指標為 DBLoad，每秒收集一次。
作用中的工作階段
資料庫工作階段代表應用程式與關聯式資料庫的對話。作用中工作階段是已提交工作給資料庫引擎且正在等待回應的連線。
工作階段處於作用中是指工作階段正在 CPU 上執行，或等待資源變成可用以繼續執行。例如，作用中工作階段可能等待分頁 (或區塊) 讀入記憶體中，然後從分頁讀取資料時耗用 CPU。
平均作用中工作階段
平均作用中工作階段 (AAS) 是 DBLoad 績效詳情的單位。它會測量資料庫上同時處於作用中狀態的工作階段數目。
每一秒，績效詳情都會取樣同時執行查詢的工作階段數目。針對每個作用中的工作階段，績效詳情會收集下列資料：
-
SQL 陳述式
-
工作階段狀態 (正在 CPU 上執行或等待中)
-
Host
-
執行 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) 與 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 大致相同。不過，由於計算的輸入是不同的資料來源，所以計算通常會略有不同。
維度
db.load 指標與其他時間序列指標不同，因為您可以將它分為名為維度的子元件。您可以將維度視為 DBLoad 指標不同特性的「配量依據」類別。
診斷效能問題時，下列維度通常最實用：
如需 Aurora 引擎的維度完整清單，請參閱 資料庫負載依維度配量。
等待事件
等待事件會導致 SQL 陳述式等待特定事件發生後，才能繼續執行。等待事件指出工作在何處受阻，是資料庫負載的重要維度或類別。
每個使用中的工作階段都在 CPU 上執行或等待中。例如，工作階段在記憶體中搜尋緩衝區、執行計算或執行程序程式碼時會耗用 CPU。當工作階段不耗用 CPU 時，可能是在等待記憶體緩衝區變成可用、要讀取的資料檔或要寫入的記錄檔。工作階段等待資源越久，在 CPU 上執行的時間就越短。
調校資料庫時，您通常會嘗試查明工作階段正在等待的資源。例如，兩個或三個等待事件可能佔資料庫負載的 90%。此量值表示作用中工作階段平均花最多時間等待少量資源。如果您可以找出這些等待的原因，就可以嘗試解決方案。
以倉庫工人的比喻為例。進來的訂單是買一本書。工人可能延遲履行訂單。例如，可能是另一名工人正在貨架上補貨、找不到可用的手推車。或者，用來輸入訂單狀態的系統可能很慢。工人等待越久，履行訂單就越久。在倉儲工作流程中，等待很平常，但如果等待時間太久，生產力會降低。同樣地，重複或冗長的工作階段等待會降低資料庫效能。如需詳細資訊，請參閱《Amazon Aurora 使用者指南》中的調校 Aurora PostgreSQL 的等待事件和調校 Aurora MySQL 的等待事件。
等待事件依據資料庫引擎而有所差異：
-
如需 Aurora MySQL 的常用等待事件清單，請參閱 Aurora MySQL 等待事件。若要了解如何使用這些等待事件來調校，請參閱調校 Aurora MySQL。
-
如需關於所有 MySQL 等待事件的資訊，請參閱 MySQL 文件中的等待事件摘要表格
。 -
如需 Aurora PostgreSQL 的常用等待事件清單，請參閱 Amazon Aurora PostgreSQL 等待事件。若要了解如何使用這些等待事件來調校，請參閱調校 Aurora PostgreSQL 的等待事件。
-
如需關於所有 PostgreSQL 等待事件的資訊，請參閱 PostgreSQL 文件中的統計數字收集器 > 等待事件表
。
最高 SQL
等待事件會顯示瓶頸，而最高 SQL 則顯示哪些查詢對資料庫負載造成最大影響。例如，許多查詢目前可能正在資料庫上執行，但單一查詢可能會耗用 99% 的資料庫負載。在此情況下，高負載可能表示查詢發生問題。
根據預設，績效詳情主控台會顯示造成資料庫負載的常用 SQL 查詢。主控台也會顯示每個陳述式的相關統計資料。若要診斷特定陳述式的效能問題，您可以檢查其執行計劃。
