本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
資料庫負載
資料庫負載 （資料庫負載） 會測量資料庫中工作階段活動的層級。 DBLoad是 Database Insights 中的關鍵指標，而 Database Insights 每秒收集資料庫負載。
作用中的工作階段
資料庫工作階段代表應用程式與關聯式資料庫的對話。作用中工作階段是已提交工作給資料庫引擎且正在等待回應的連線。
工作階段處於作用中是指工作階段正在 CPU 上執行，或等待資源變成可用以繼續執行。例如，作用中工作階段可能等待分頁 (或區塊) 讀入記憶體中，然後從分頁讀取資料時耗用 CPU。
平均作用中工作階段
平均作用中工作階段 (AAS) 是 Database Insights 中DBLoad指標的單位。它會測量資料庫上同時處於作用中狀態的工作階段數目。
Database Insights 每秒會取樣同時執行查詢的工作階段數量。對於每個作用中工作階段， Database Insights 會收集下列資料：
-
SQL 陳述式
-
工作階段狀態 (正在 CPU 上執行或等待中)
-
主機
-
執行 SQL 的使用者
Database Insights 計算 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 個工作階段處於作用中。
平均作用中執行數
每秒平均作用中執行數 (AAE) 與 AAS 相關。為了計算 AAE， Database Insights 會將查詢的總執行時間除以時間間隔。下表顯示上表中同一個查詢的 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 指標不同特性的「配量依據」類別。
診斷效能問題時，下列維度通常最實用：
如需 Amazon RDS Aurora引擎維度的完整清單，請參閱 Database Insights。
等待事件
等待事件會導致 SQL 陳述式等待特定事件發生後，才能繼續執行。等待事件指出工作在何處受阻，是資料庫負載的重要維度或類別。
每個使用中的工作階段都在 CPU 上執行或等待中。例如，工作階段在記憶體中搜尋緩衝區、執行計算或執行程序程式碼時會耗用 CPU。當工作階段不耗用 CPU 時，可能是在等待記憶體緩衝區變成可用、要讀取的資料檔或要寫入的記錄檔。工作階段等待資源越久，在 CPU 上執行的時間就越短。
調校資料庫時，您通常會嘗試查明工作階段正在等待的資源。例如，兩個或三個等待事件可能佔資料庫負載的 90%。此量值表示作用中工作階段平均花最多時間等待少量資源。如果您可以找出這些等待的原因，就可以嘗試解決方案。
等待事件依據資料庫引擎而有所差異：
-
如需關於所有 MariaDB 和 MySQL 等待事件的資訊，請參閱 MySQL 文件中的等待事件摘要表格
。 -
如需關於所有 PostgreSQL 等待事件的資訊，請參閱 PostgreSQL 文件中的統計數字收集器 > 等待事件表
。 -
如需關於所有 Oracle 等待事件的資訊，請參閱 Oracle 文件中的等待事件說明
。 -
如需所有 SQL Server 等待事件的相關資訊，請參閱 SQL 文件中的等待類別
。
注意
對於 Oracle，背景程序有時不需要相關的 SQL 陳述式即可發揮作用。在這些情況下， Database Insights 會報告與冒號串連的背景程序類型，以及與該背景程序相關聯的等待類別。背景程序的類型包括 LGWR、ARC0、PMON 等。
例如，當封存程式執行 I/O 時，其 Database Insights 報告類似於 ARC1:System I/O。有時候，背景程序類型也會遺失，而 Database Insights 只會報告等待類別，例如 :System I/O。
最高 SQL
等待事件會顯示瓶頸，而最高 SQL 則顯示哪些查詢對資料庫負載造成最大影響。例如，許多查詢目前可能正在資料庫上執行，但單一查詢可能會耗用 99% 的資料庫負載。在此情況下，高負載可能表示查詢發生問題。
根據預設， Database Insights 主控台會顯示導致資料庫載入的熱門 SQL 查詢。主控台也會顯示每個陳述式的相關統計資料。若要診斷特定陳述式的效能問題，您可以檢查其執行計劃。
計畫
執行計畫簡稱為計畫，是存取資料的一連串步驟。例如，聯結資料表 t1 和 t2 的計畫，可能會循環 t1 中的所有資料列，並將每一列與 t2 中的某列做比較。在關聯式資料庫中，內建程式碼最佳化工具可為 SQL 查詢最決定最有效的計畫。
對於資料庫執行個體， Database Insights 會自動收集執行計畫。若要診斷 SQL 效能問題，請檢查擷取的計畫是否有耗用大量資源的 SQL 查詢。這些計畫顯示資料庫如何剖析和執行查詢。
若要了解如何使用計劃分析資料庫負載，請參閱 Database Insights。
計畫擷取
Database Insights 每五分鐘會識別資源最密集的查詢，並擷取其計劃。因此您不需要手動收集和管理大量的計畫。而是可以使用 Top SQL (最高 SQL) 索引標籤，將重點放在問題最大的查詢的計畫上。
注意
Database Insights 不會針對文字超過可收集查詢文字上限的查詢擷取計劃。如需詳細資訊，請參閱 Database Insights。
執行計畫的保留期與 Database Insights 資料相同。保留設定為預設值 (7 天)。若要更長時間保留績效資料，請指定 1 - 24 個月。如需保留期間的詳細資訊，請參閱 Database Insights 的定價和資料保留。
摘要查詢
Top SQL (最高 SQL) 索引標籤預設顯示摘要查詢。摘要查詢本身沒有計畫，但使用文字值的所有查詢都具有計畫。例如，摘要查詢可能包含文字 WHERE `email`=?。摘要可能包含兩個查詢，其中一個具有文字 WHERE email=user1@example.com，另一個含有 WHERE
email=user2@example.com。這些文字查詢全都可能包含多個計畫。
當您選取一個摘要查詢，主控台就會顯示所選摘要子陳述式的所有計畫。因此，您不需要查看所有的子陳述式來尋找計畫。您可能會看到前 10 個子陳述式清單中沒有顯示的計畫。主控台顯示已收集計畫的所有子查之計畫，無論這些查詢是否排入前 10 名。
