本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 調校 Aurora MySQL
等待事件和執行緒狀態是 Aurora MySQL 的重要調校工具。如果您可以了解工作階段為何等待資源及其運作情形，就更能夠減少瓶頸。您可以使用本節的資訊來尋找可能的原因和更正動作。
Amazon DevOps Guru for RDS 可以主動判斷您的 Aurora MySQL 資料庫是否出現可能導致嚴重後果的問題。Amazon DevOps Guru for RDS 會在主動洞察中發佈修正動作的說明和建議。本區段包含常見問題的洞察。
**重要**
本節中的等待事件和執行緒狀態是 Aurora MySQL 特有的。本節資訊僅適用於調校 Amazon Aurora，而不適用於 Amazon RDS for MySQL。
本節部分等待事件在這些資料庫引擎的開放原始碼版本中沒有對等的事件。其他等待事件與開放原始碼引擎中的事件同名，但行為不同。例如，Amazon Aurora 儲存與開放原始碼儲存的運作方式不同，因此與儲存相關的等待事件表示不同的資源條件。
**Topics**
+ [Aurora MySQL 調校的基本概念](AuroraMySQL.Managing.Tuning.concepts.md)
+ [使用等待事件調校 Aurora MySQL](AuroraMySQL.Managing.Tuning.wait-events.md)
+ [使用執行緒狀態調校 Aurora MySQL](AuroraMySQL.Managing.Tuning.thread-states.md)
+ [使用 Amazon DevOps Guru 主動洞察，調校 Aurora MySQL](MySQL.Tuning.proactive-insights.md)
# Aurora MySQL 調校的基本概念
調校 Aurora MySQL 資料庫之前，請務必先了解什麼是等待事件和執行緒狀態及其發生原因。使用 InnoDB 儲存引擎時，亦請檢閱 Aurora MySQL 的基本記憶體和磁碟架構。如需實用的架構圖，請參閱 [MySQL 參考手冊](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html)。
**Topics**
+ [Aurora MySQL 等待事件](#AuroraMySQL.Managing.Tuning.concepts.waits)
+ [Aurora MySQL 執行緒狀態](#AuroraMySQL.Managing.Tuning.concepts.thread-states)
+ [Aurora MySQL 記憶體](#AuroraMySQL.Managing.Tuning.concepts.memory)
+ [Aurora MySQL 處理](#AuroraMySQL.Managing.Tuning.concepts.processes)
## Aurora MySQL 等待事件
「等待事件」**表示工作階段正在等待的資源。例如，等待事件 `io/socket/sql/client_connection` 表示執行緒正在處理新連線。工作階段等待的典型資源包括：
+ 透過單一執行緒存取緩衝區，例如，當工作階段嘗試修改緩衝區時
+ 另一個工作階段目前鎖定的資料列
+ 資料檔讀取
+ 日誌檔寫入
例如，為了滿足查詢，工作階段可能執行完整的資料表掃描。如果資料不在記憶體中，工作階段會等待磁碟輸入/輸出完成。將緩衝區讀入記憶體後，工作階段可能需要等待，因為其他工作階段正在存取這些緩衝區。資料庫使用預先定義的等待事件來記錄等待。這些事件分組為多個類別。
等待事件本身不表示有效能問題。例如，如果請求的資料不在記憶體中，則需要從磁碟讀取資料。如果一個工作階段鎖定資料列來更新，則另一個工作階段要等待此資料列解除鎖定才能更新。遞交需要等待寫入日誌檔完成。等待是資料庫正常運作所不可或缺。
大量等待事件通常表示有效能問題。在這種情況下，您可以使用等待事件資料來判斷工作階段將時間花在何處。例如，如果報告通常執行幾分鐘，但現在執行數小時，您可以識別佔總等待時間最多的等待事件。如果您可以查出最常等待事件的原因，通常就能做些改變來改善效能。例如，如果工作階段等待的資料列被另一個工作階段鎖定，您可以結束該鎖定工作階段。
## Aurora MySQL 執行緒狀態
「一般執行緒狀態」**是與一般查詢處理相關聯的 `State` 值。例如，執行緒狀態 `sending data` 表示執行緒正在讀取和篩選查詢的資料列，以決定正確的結果集。
您可以使用執行緒狀態，以類似於使用等待事件的方式調校 Aurora MySQL。例如，頻繁發生 `sending data` 通常表示查詢未使用索引。如需執行緒狀態的詳細資訊，請參閱《MySQL 參考手冊》**中的[一般執行緒狀態](https://dev.mysql.com/doc/refman/5.7/en/general-thread-states.html)。
使用績效詳情時，下列其中一個條件為 true：
+ 效能結構描述已開啟 – Aurora MySQL 顯示等待事件，而不是執行緒狀態。
+ 效能結構描述未開啟 – Aurora MySQL 顯示執行緒狀態。
建議您設定效能結構描述進行自動管理。效能結構描述提供其他洞察和更好的工具，以調查潛在的效能問題。如需更多詳細資訊，請參閱 [Aurora MySQL 上 Performance Insights 的效能結構描述概觀](USER_PerfInsights.EnableMySQL.md)。
## Aurora MySQL 記憶體
在 Aurora MySQL 中，最重要的記憶體區域是緩衝集區和日誌緩衝區。
**Topics**
+ [緩衝集區](#AuroraMySQL.Managing.Tuning.concepts.memory.buffer-pool)
### 緩衝集區
「緩衝集區」**是 Aurora MySQL 快取資料表和檢索資料的共用記憶體區域。查詢可以直接從記憶體存取經常使用的資料，而無需從磁碟讀取。
緩衝集區會建構為頁面的鏈結清單。一個「頁面」**可以保留多個資料列。Aurora MySQL 會使用最近最少使用 (LRU) 演算法，使頁面過時而移出集區。
如需詳細資訊，請參閱《*MySQL 參考手冊*》中的[緩衝集區](https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html)。
## Aurora MySQL 處理
Aurora MySQL 使用的程序模型與 Aurora PostgreSQL 非常不同。
**Topics**
+ [MySQL 伺服器 (mysqld)](#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)
+ [執行緒](#AuroraMySQL.Managing.Tuning.concepts.processes.threads)
+ [執行緒集區](#AuroraMySQL.Managing.Tuning.concepts.processes.pool)
### MySQL 伺服器 (mysqld)
MySQL 伺服器是名為 mysqld 的單一作業系統程序。MySQL 伺服器不會產生額外的程序。因此，Aurora MySQL 資料庫會使用 mysqld 來執行其大部分工作。
當 MySQL 伺服器啟動時，它會接聽來自 MySQL 用戶端的網路連線。當用戶端連接到資料庫時，mysqld 會開啟一個執行緒。
### 執行緒
連線管理員執行緒會將每個用戶端連線與專用執行緒建立關聯。此執行緒會管理身分驗證、執行陳述式，並將結果傳回至用戶端。連線管理員會在必要時建立新的執行緒。
「執行緒快取」**是一組可用的執行緒。當連線結束時，如果快取未滿，MySQL 會將執行緒傳回至執行緒快取。`thread_cache_size` 系統變數會決定執行緒快取大小。
### 執行緒集區
「執行緒集區」**包含許多執行緒群組。每個群組都會管理一組用戶端連線。當用戶端連線到資料庫時，執行緒集區會以循環方式將連線指派給執行緒群組。執行緒集區會將連線和執行緒隔開。連線與執行從這些連線收到之陳述式的執行緒之間沒有固定關係。
# 使用等待事件調校 Aurora MySQL
下表彙總了最常表示效能問題的 Aurora MySQL 等待事件。下列等待事件是 [Aurora MySQL 等待事件](AuroraMySQL.Reference.Waitevents.md)中的清單子集。
| 等待事件 | 說明 |
| --- | --- |
| [cpu](ams-waits.cpu.md) | 此事件表示執行緒活躍於 CPU 中或正在等待 CPU。 |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | 當工作階段將持久性資料寫入至 Aurora 儲存體時，此事件便會發生。 |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | 當執行緒正在等待將結果集傳回至用戶端時，此事件便會發生。 |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | 當工作階段將持久性資料寫入至 Aurora 儲存體時，此事件便會發生。 |
| [io/socket/sql/client\$1connection](ams-waits.client-connection.md) | 當執行緒正在處理新連線時，此事件便會發生。 |
| [io/table/sql/handler](ams-waits.waitio.md) | 當工作已委派給儲存引擎時，此事件便會發生。 |
| [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md) | 當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，此事件便會發生。 |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | 當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，此事件便會發生。 |
| [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) | 有執行緒正在等待資料表中繼資料鎖定時，此事件便會發生。 |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | 當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，此事件便會發生。 |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | 當執行緒已對 InnoDB 緩衝集區取得鎖定來存取記憶體中的頁面時，此事件便會發生。 |
| [synch/mutex/innodb/fil\$1mutex](ams-waits.innodb-fil-system-mutex.md) | 當工作階段正在等待存取資料表空間記憶體快取時，此事件便會發生。 |
| [synch/mutex/innodb/fil\$1mutex](ams-waits.trxsysmutex.md) | 由於大量交易而有高資料庫活動時，此事件便會發生。 |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | 當緩衝集區中找不到的頁面必須從檔案讀取時，此事件便會發生。 |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | 當工作階段正在等待取得互斥以管理工作階段暫存資料表空間集區時，就會發生此事件。 |
# cpu
`cpu` 等待事件表示執行緒活躍於 CPU 中或正在等待 CPU。
**Topics**
+ [支援的引擎版本](#ams-waits.cpu.context.supported)
+ [Context](#ams-waits.cpu.context)
+ [等待變多的可能原因](#ams-waits.cpu.causes)
+ [動作](#ams-waits.cpu.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
對於每個 vCPU，連線都可以在此 CPU 上執行工作。在某些情況下，準備好執行的作用中連線數量高於 vCPU 的數量。這種不平衡會導致連線等待 CPU 資源。如果作用中連線的數量持續地高於 vCPU 的數量，則您的執行個體會遭遇 CPU 爭用。爭用會導致 `cpu` 等待事件發生。
**注意**
CPU 的績效詳情指標為 `DBLoadCPU`。`DBLoadCPU` 的值與 CloudWatch 指標 `CPUUtilization` 的值可能不同。後者是從 HyperVisor 為資料庫執行個體收集的指標。
績效詳情作業系統指標提供 CPU 使用率的詳細資訊。例如，您可以顯示下列指標：
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
績效詳情以 `os.cpuUtilization.nice.avg` 報告資料庫引擎的 CPU 使用率。
## 等待變多的可能原因
此事件比平時更常發生時，可能表示有效能問題，典型原因包括：
+ 分析查詢
+ 高度並行交易
+ 長時間執行的交易
+ 連線數量突然增加，稱為「登入風暴」**
+ 內容切換變多
## 動作
如果 `cpu` 等待事件在資料庫活動中佔多數，則不見得表示有效能問題。效能降低時才需要回應此事件。
根據 CPU 使用率增加的原因，請考慮下列策略：
+ 增加主機的 CPU 容量。這種方法通常只是應急而已。
+ 識別潛在最佳化的熱門查詢。
+ 如適用，請將一些唯讀工作負載重新導向至讀取器節點
**Topics**
+ [識別造成問題的工作階段或查詢](#ams-waits.cpu.actions.az-vpc-subnet)
+ [分析並最佳化高 CPU 工作負載](#ams-waits.cpu.actions.db-instance-class)
### 識別造成問題的工作階段或查詢
若要尋找工作階段和查詢，請查看績效詳情中的 **Top SQL** (最高 SQL) 資料表，以取得 CPU 負載最高的 SQL 陳述句。如需詳細資訊，請參閱[使用績效詳情儀表板來分析指標](USER_PerfInsights.UsingDashboard.md)。
通常，一或兩個 SQL 陳述式會耗用大部分的 CPU 週期。將精力集中在這些陳述式上。假設您的資料庫執行個體有 2 個 vCPU，資料庫負載為 3.1 平均作用中工作階段 (AAS)，全部都處於 CPU 狀態。在此情況下，您的執行個體受到 CPU 限制。請考慮下列策略：
+ 升級至 vCPU 更多的大型執行個體類別。
+ 調校您的查詢以降低 CPU 負載。
在此範例中，最高 SQL 查詢具有 1.5 AAS 的資料庫負載，全部都處於 CPU 狀態。另一個 SQL 陳述式在 CPU 狀態下有 0.1 的負載。在此範例中，如果您已停止負載最低的 SQL 陳述式，則不會大幅減少資料庫負載。不過，如果您將兩個高負載查詢最佳化為效率的兩倍，則可以消除 CPU 瓶頸。如果您將 1.5 AAS 的 CPU 負載減少 50%，則每個陳述式的 AAS 會降低至 0.75。CPU 上花費的總資料庫負載現在為 1.6 AAS。此值低於最大 vCPU 數線，即 2.0。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。另請參閱 AWS 支援文章 [如何疑難排解和解決 Amazon RDS for MySQL 執行個體上的高 CPU 使用率？](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/)。
### 分析並最佳化高 CPU 工作負載
在找出增加 CPU 使用率的查詢之後，您可以將其最佳化或結束連線。下列範例示範如何結束連線。
```
CALL mysql.rds_kill(processID);
```
如需詳細資訊，請參閱[mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill)。
如果您結束工作階段，動作可能會觸發長時間回復。
#### 遵循最佳化查詢的指導方針
若要最佳化查詢，請考慮以下指導方針：
+ 執行 `EXPLAIN` 陳述式。
這個命令會顯示執行查詢所涉及的個別步驟。如需詳細資訊，請參閱 MySQL 文件中的[利用 EXPLAIN 最佳化查詢](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html)。
+ 執行 `SHOW PROFILE` 陳述式。
使用此陳述式可檢閱設定檔詳細資訊，此詳細資訊可以指出在目前工作階段期間執行之陳述式的資源使用情形。如需詳細資訊，請參閱 MySQL 文件中的 [SHOW PROFILE 陳述式](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html)。
+ 執行 `ANALYZE TABLE` 陳述式。
使用此陳述式，可重新整理高 CPU 耗用查詢所存取之資料表的索引統計資料。藉由分析敘述句，您可以協助最佳化工具選擇適當的執行計劃。如需詳細資訊，請參閱 MySQL 文件中的 [ANALYZE TABLE 陳述式](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html)。
#### 遵循改善 CPU 使用率的指導方針
若要改善資料庫執行個體中的 CPU 使用率，請遵循下列指導方針：
+ 確保所有查詢都是使用適當的索引。
+ 了解您是否可以使用 Aurora 平行查詢。您可以使用此技術，減少前端節點上的 CPU 使用量，方法是下推 `WHERE` 子句的函數處理、資料列篩選和資料欄投影。
+ 了解每秒 SQL 執行次數是否符合預期的閾值。
+ 了解索引維護或建立新索引是否佔用生產工作負載所需的 CPU 週期。將維護活動排定在尖峰活動時間之外。
+ 了解您是否可以使用分割來協助減少查詢資料集。如需詳細資訊，請參閱部落格文章[如何為合併的工作負載規劃並最佳化 Amazon Aurora 與 MySQL 相容性](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/)。
#### 檢查連線風暴
如果 `DBLoadCPU` 指標不是非常高，但 `CPUUtilization` 指標很高，CPU 使用率高的原因是在資料庫引擎之外造成的。典型範例是連線風暴。
檢查下列條件是否為 true：
+ 績效詳情 `CPUUtilization` 指標和 Amazon CloudWatch `DatabaseConnections` 指標都有所增加。
+ CPU 中的執行緒數量大於 vCPU 的數量。
如果上述條件為 true，請考慮減少資料庫連線數量。例如，您可以使用連線集區，如 RDS Proxy。若要了解有效連線管理和擴展的最佳實務，請參閱白皮書[用於連線管理的 Amazon Aurora MySQL DBA 手冊](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)。
# io/aurora\$1redo\$1log\$1flush
當工作階段將持久性資料寫入至 Amazon Aurora 儲存體時，`io/aurora_redo_log_flush` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.io-auredologflush.context.supported)
+ [Context](#ams-waits.io-auredologflush.context)
+ [等待時間增加的可能原因](#ams-waits.io-auredologflush.causes)
+ [動作](#ams-waits.io-auredologflush.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版
## Context
`io/aurora_redo_log_flush` 事件適用於 Aurora MySQL 中的寫入輸入/輸出 (輸入/輸出) 作業。
**注意**
在 Aurora MySQL 第 3 版中，此等待事件名為 [io/redo\$1log\$1flush](ams-waits.io-redologflush.md)。
## 等待時間增加的可能原因
對於資料持久性，遞交需要持久寫入至穩定的儲存。如果資料庫執行太多的遞交，寫入輸入/輸出作業上會有等待事件，即 `io/aurora_redo_log_flush` 等待事件。
在下列範例中，會使用 db.r5.xlarge 資料庫執行個體類別，將 50,000 筆記錄插入至 Aurora MySQL 資料庫叢集：
+ 在第一個範例中，每個工作階段逐列插入 10,000 筆記錄。根據預設，如果資料處理語言 (DML) 命令不在交易內，Aurora MySQL 會使用隱含遞交。系統會開啟自動遞交。這表示對於每個資料列插入都有一個遞交。績效詳情顯示，連線花費其大部分時間等待 `io/aurora_redo_log_flush` 等待事件。
![\[等待事件的績效詳情範例\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
這是由使用的簡單插入陳述式引起的。
![\[在最高 SQL 中插入陳述式\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
插入 50,000 筆記錄需要 3.5 分鐘。
+ 在第二個範例中，插入是以 1,000 個批次進行，亦即每個連線執行 10 個遞交，而不是 10,000 個。績效詳情顯示，連線不會將其大部分時間花費在 `io/aurora_redo_log_flush` 等待事件上。
![\[影響較少之等待事件的績效詳情範例\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
插入 50,000 筆記錄需要 4 秒。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別有問題的工作階段和查詢](#ams-waits.io-auredologflush.actions.identify-queries)
+ [將您的寫入作業分組](#ams-waits.io-auredologflush.actions.action0)
+ [關閉自動遞交](#ams-waits.io-auredologflush.actions.action1)
+ [使用交易](#ams-waits.io-auredologflush.action2)
+ [使用批次](#ams-waits.io-auredologflush.action3)
### 識別有問題的工作階段和查詢
如果您的資料庫執行個體遭遇瓶頸，您的第一項任務是尋找造成瓶頸的工作階段和查詢。如需實用的 AWS 資料庫部落格文章，請參閱[使用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
**識別造成瓶頸的工作階段和查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。
1. 在 **Database load** (資料庫負載) 中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
清單頂端的查詢對資料庫造成最高負載。
### 將您的寫入作業分組
下列範例會觸發 `io/aurora_redo_log_flush` 等待事件。(系統會開啟自動遞交)。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
若要減少等待 `io/aurora_redo_log_flush` 等待事件所花費的時間，將您的寫入作業邏輯分組為單一遞交，以減少持續呼叫儲存。
### 關閉自動遞交
在進行不在交易內的大規模變更之前，請先關閉自動遞交，如下列範例所示。
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### 使用交易
您可以使用交易，如下列範例所示。
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### 使用批次
您也可以批次進行變更，如下列範例所示。不過，使用過大的批次可能會導致效能問題，尤其是在僅供讀取複本中或在執行時間點復原 (PITR) 時。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
當執行緒正在等待將結果集傳回至用戶端時，`io/aurora_respond_to_client` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.respond-to-client.context.supported)
+ [Context](#ams-waits.respond-to-client.context)
+ [等待變多的可能原因](#ams-waits.respond-to-client.causes)
+ [動作](#ams-waits.respond-to-client.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版
## Context
事件 `io/aurora_respond_to_client` 指出執行緒正在等待將結果集傳回至用戶端時。
查詢處理完成，且結果會傳回至應用程式用戶端。不過，由於資料庫叢集上沒有足夠的網路頻寬，因此執行緒正在等待傳回結果集。
## 等待變多的可能原因
`io/aurora_respond_to_client` 事件比平時更常出現時，可能表示有效能問題，典型原因包括：
**資料庫執行個體類別不足以處理工作負載**
資料庫叢集所使用的資料庫執行個體類別沒有必要的網路頻寬來有效處理工作負載。
**大型結果集**
傳回的結果集大小增加，因為查詢傳回大量的資料列。結果集越大，耗用的網路頻寬就越多。
**用戶端的負載增加**
用戶端可能面臨 CPU 壓力、記憶體壓力或網路飽和。用戶端的負載增加會延遲從 Aurora MySQL 資料庫叢集接收資料。
**網路延遲較久**
Aurora MySQL 資料庫叢集與用戶端之間的網路延遲可能變長。網路延遲越久會導致用戶端需要更多時間來接收資料。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.respond-to-client.actions.identify)
+ [擴展資料庫執行個體類別](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [檢查工作負載是否有非預期結果](#ams-waits.respond-to-client.actions.workload)
+ [使用讀取器執行個體分配工作負載](#ams-waits.respond-to-client.actions.balance)
+ [使用 SQL\$1BUFFER\$1RESULT 修飾詞](#ams-waits.respond-to-client.actions.sql-buffer-result)
### 識別造成事件的工作階段和查詢
您可以使用績效詳情來顯示 `io/aurora_respond_to_client` 等待事件所封鎖的查詢。通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**尋找負責高負載的 SQL 查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行故障診斷的實用概觀，請參閱 AWS 資料庫部落格文章[使用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 擴展資料庫執行個體類別
檢查與網路輸送量 (例如 `NetworkReceiveThroughput` 和 `NetworkTransmitThroughput`) 相關的 Amazon CloudWatch 指標值是否增加。如果達到資料庫執行個體類別的網路頻寬，您可以修改資料庫叢集來擴展資料庫叢集所使用的資料庫執行個體。具有較大網路頻寬的資料庫執行個體類別可更有效率地將資料傳回至用戶端
如需監控 Amazon CloudWatch 指標的相關資訊，請參閱[在 Amazon RDS 主控台中檢視指標](USER_Monitoring.md)。如需資料庫執行個體類別的相關資訊，請參閱 [Amazon Aurora 資料庫執行個體類別](Concepts.DBInstanceClass.md)。如需修改資料庫叢集的詳細資訊，請參閱 [修改 Amazon Aurora 資料庫叢集](Aurora.Modifying.md)。
### 檢查工作負載是否有非預期結果
檢查資料庫叢集上的工作負載，並確定它不會產生非預期的結果。例如，可能有查詢傳回比預期還要多的資料列。在此情況下，您可以使用績效詳情計數器指標，例如 `Innodb_rows_read`。如需詳細資訊，請參閱[Performance Insights 計數器指標](USER_PerfInsights_Counters.md)。
### 使用讀取器執行個體分配工作負載
您可以使用 Aurora 複本分配唯讀工作負載。您可以新增更多的 Aurora 複本來水平擴展。這樣做可能會提高網路頻寬的調節限制。如需詳細資訊，請參閱[Amazon Aurora 資料庫叢集](Aurora.Overview.md)。
### 使用 SQL\$1BUFFER\$1RESULT 修飾詞
您可以將 `SQL_BUFFER_RESULT` 修飾詞新增至 `SELECT` 陳述式，在將結果傳回至用戶端之前，強制將這些結果放入暫時資料表中。當 InnoDB 鎖定由於查詢處於 `io/aurora_respond_to_client` 等待狀態而未釋放時，此修飾詞可以協助解決效能問題。如需詳細資訊，請參閱 MySQL 文件中的 [SELECT PROFILE 陳述式](https://dev.mysql.com/doc/refman/5.7/en/select.html)。
# io/redo\$1log\$1flush
當工作階段將持久性資料寫入至 Amazon Aurora 儲存體時，`io/redo_log_flush` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.io-redologflush.context.supported)
+ [Context](#ams-waits.io-redologflush.context)
+ [等待時間增加的可能原因](#ams-waits.io-redologflush.causes)
+ [動作](#ams-waits.io-redologflush.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 3 版
## Context
`io/redo_log_flush` 事件適用於 Aurora MySQL 中的寫入輸入/輸出 (輸入/輸出) 作業。
**注意**
在 Aurora MySQL 第 2 版中，此等待事件名為 [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)。
## 等待時間增加的可能原因
對於資料持久性，遞交需要持久寫入至穩定的儲存。如果資料庫執行太多的遞交，寫入輸入/輸出作業上會有等待事件，即 `io/redo_log_flush` 等待事件。
如需此等待事件行為的範例，請參閱 [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別有問題的工作階段和查詢](#ams-waits.io-redologflush.actions.identify-queries)
+ [將您的寫入作業分組](#ams-waits.io-redologflush.actions.action0)
+ [關閉自動遞交](#ams-waits.io-redologflush.actions.action1)
+ [使用交易](#ams-waits.io-redologflush.action2)
+ [使用批次](#ams-waits.io-redologflush.action3)
### 識別有問題的工作階段和查詢
如果您的資料庫執行個體遭遇瓶頸，您的第一項任務是尋找造成瓶頸的工作階段和查詢。如需實用的 AWS 資料庫部落格文章，請參閱[使用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
**識別造成瓶頸的工作階段和查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。
1. 在 **Database load** (資料庫負載) 中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
清單頂端的查詢對資料庫造成最高負載。
### 將您的寫入作業分組
下列範例會觸發 `io/redo_log_flush` 等待事件。(系統會開啟自動遞交)。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
若要減少等待 `io/redo_log_flush` 等待事件所花費的時間，將您的寫入作業邏輯分組為單一遞交，以減少持續呼叫儲存。
### 關閉自動遞交
在進行不在交易內的大規模變更之前，請先關閉自動遞交，如下列範例所示。
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### 使用交易
您可以使用交易，如下列範例所示。
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### 使用批次
您也可以批次進行變更，如下列範例所示。不過，使用過大的批次可能會導致效能問題，尤其是在僅供讀取複本中或在執行時間點復原 (PITR) 時。
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
當執行緒正在處理新連線時，`io/socket/sql/client_connection` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.client-connection.context.supported)
+ [Context](#ams-waits.client-connection.context)
+ [等待變多的可能原因](#ams-waits.client-connection.causes)
+ [動作](#ams-waits.client-connection.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
事件 `io/socket/sql/client_connection` 指出 mysqld 忙於建立執行緒來處理傳入的新用戶端連線。在此情況中，當連線等待要指派的執行緒時，服務新的用戶端連線請求的處理速度會減慢。如需詳細資訊，請參閱[MySQL 伺服器 (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld)。
## 等待變多的可能原因
此事件比平時更常出現時，可能表示有效能問題，典型原因包括：
+ 從應用程式到 Amazon RDS 執行個體的新使用者連線突然增加。
+ 您的資料庫執行個體無法處理新連線，因為網路、CPU 或記憶體正在調節。
## 動作
如果 `io/socket/sql/client_connection` 主導資料庫活動，則不見得表示有效能問題。在不是閒置的資料庫中，等待事件始終位於頂端。只有在效能降低時才採取行動。根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別有問題的工作階段和查詢](#ams-waits.client-connection.actions.identify-queries)
+ [遵循連線管理的最佳實務](#ams-waits.client-connection.actions.manage-connections)
+ [如果資源正在調節，請擴展執行個體](#ams-waits.client-connection.upgrade)
+ [檢查最高主機和最高使用者](#ams-waits.client-connection.top-hosts)
+ [查詢 performance\$1schema 資料表](#ams-waits.client-connection.perf-schema)
+ [檢查查詢的執行緒狀態](#ams-waits.client-connection.thread-states)
+ [稽核請求和查詢](#ams-waits.client-connection.auditing)
+ [集中資料庫連線](#ams-waits.client-connection.pooling)
### 識別有問題的工作階段和查詢
如果您的資料庫執行個體遭遇瓶頸，您的第一項任務是尋找造成瓶頸的工作階段和查詢。如需實用的部落格文章，請參閱[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
**識別造成瓶頸的工作階段和查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。
1. 在 **Database load** (資料庫負載) 中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
清單頂端的查詢對資料庫造成最高負載。
### 遵循連線管理的最佳實務
若要管理連線，請考慮下列策略：
+ 使用連線集區
您可以視需要逐漸增加連線數量。如需詳細資訊，請參閱白皮書 [Amazon Aurora MySQL 資料庫管理員手冊](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf)。
+ 使用讀取器節點重新分配唯讀流量。
如需更多詳細資訊，請參閱 [Aurora 複本](Aurora.Replication.md#Aurora.Replication.Replicas)及 [Amazon Aurora 端點連線](Aurora.Overview.Endpoints.md)。
### 如果資源正在調節，請擴展執行個體
在下列資源中尋找調節的範例：
+ CPU
檢查 Amazon CloudWatch 指標是否有高 CPU 使用率。
+ 網路
檢查 CloudWatch 指標 `network receive throughput` 和 `network transmit throughput` 的值是否增加。如果您的執行個體已達到執行個體類別的網路頻寬限制，請考慮將 RDS 執行個體擴展到更高的執行個體類別類型。如需詳細資訊，請參閱[Amazon Aurora 資料庫執行個體類別](Concepts.DBInstanceClass.md)。
+ 可用記憶體
檢查 CloudWatch 指標 `FreeableMemory` 是否下降。此外，請考慮開啟增強型監控。如需詳細資訊，請參閱[使用增強型監控來監控作業系統指標](USER_Monitoring.OS.md)。
### 檢查最高主機和最高使用者
使用績效詳情來檢查最高主機和最高使用者。如需詳細資訊，請參閱[使用績效詳情儀表板來分析指標](USER_PerfInsights.UsingDashboard.md)。
### 查詢 performance\$1schema 資料表
若要取得目前和總連線的準確計數，請查詢 `performance_schema` 資料表。使用此技術，您可以識別負責建立大量連線的來源使用者或主機。例如，查詢 `performance_schema` 資料表，如下所示。
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### 檢查查詢的執行緒狀態
如果效能問題持續發生，請檢查查詢的執行緒狀態。在 `mysql` 用戶端中，發出下列命令。
```
show processlist;
```
### 稽核請求和查詢
若要從使用者帳戶檢查請求和查詢的性質，請使用 Aurora MySQL 進階稽核。若要了解如何開啟稽核，請參閱[使用進階稽核與 Amazon Aurora MySQL 資料庫叢集搭配](AuroraMySQL.Auditing.md)。
### 集中資料庫連線
考慮使用 Amazon RDS Proxy 進行連線管理。透過使用 RDS Proxy，您可以允許應用程式集中和共用資料庫連線，以改善其擴展能力。RDS Proxy 會自動連線至待命資料庫執行個體，同時保留應用程式連線，使應用程式更具有資料庫故障彈性。如需詳細資訊，請參閱[Amazon RDS Proxy for Aurora](rds-proxy.md)。
# io/table/sql/handler
當工作已委派給儲存引擎時，`io/table/sql/handler` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.waitio.context.supported)
+ [Context](#ams-waits.waitio.context)
+ [等待時間增加的可能原因](#ams-waits.waitio.causes)
+ [動作](#ams-waits.waitio.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
事件 `io/table` 指出等待存取資料表。無論是在緩衝集區中快取資料，還是在磁碟上存取資料，都會發生此事件。`io/table/sql/handler` 事件表示工作負載活動增加。
「處理常式」**是專門處理特定類型的資料或專注於某些特殊任務的常式。例如，事件處理常式會接收和摘錄來自作業系統或使用者界面的事件和訊號。記憶體處理常式會執行與記憶體相關的任務。文件輸入處理常式是接收檔案輸入，並根據內容對資料執行特殊任務的函數。
當實際等待是巢狀等待事件 (例如鎖定) 時，`performance_schema.events_waits_current` 這類的檢視經常顯示 `io/table/sql/handler`。當實際的等待不是 `io/table/sql/handler` 時，績效詳情會報告巢狀等待事件。當 Performance Insights 報告 `io/table/sql/handler` 時，它代表 I/O 請求的 InnoDB 處理，而不是隱藏的巢狀等待事件。如需詳細資訊，請參閱 *MySQL 參考手冊*中的[效能結構描述原子和分子事件](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)。
`io/table/sql/handler` 事件通常會與 I/O 等待 (例如 `io/aurora_redo_log_flush`) 一起出現在最久等待事件中。
## 等待時間增加的可能原因
在績效詳情中，`io/table/sql/handler` 事件中的突然峰值表示工作負載活動增加。活動增加意味著輸入/輸出增加。
績效詳情會篩選巢狀事件 ID，而且在基礎巢狀事件是鎖等待時不會報告 `io/table/sql/handler` 等待。例如，如果根本原因事件是 [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)，績效詳情會在最高等待事件中顯示此等待，而不是 `io/table/sql/handler`。
在 `performance_schema.events_waits_current` 這類的檢視中，當實際等待是巢狀等待事件 (例如鎖定) 時，`io/table/sql/handler` 的等待通常就會出現。當實際等待與 `io/table/sql/handler` 不同時，績效詳情會查閱巢狀等待，並報告實際等待，而不是 `io/table/sql/handler`。當績效詳情報告 `io/table/sql/handler` 時，真正的等待是 `io/table/sql/handler`，而不是隱藏的巢狀等待事件。如需詳細資訊，請參閱 *MySQL 5.7 參考手冊*中的[效能結構描述原子和分子事件](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html)。
## 動作
如果此等待事件主導資料庫活動，則不見得表示有效能問題。當資料庫作用中時，等待事件一律在頂端。只有在效能降低時才需要採取行動。
我們會建議不同的動作，取決於您看到的其他等待事件。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.waitio.actions.identify)
+ [檢查是否與績效詳情計數器指標關聯](#ams-waits.waitio.actions.filters)
+ [檢查是否有其他關聯的等待事件](#ams-waits.waitio.actions.maintenance)
### 識別造成事件的工作階段和查詢
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**尋找負責高負載的 SQL 查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 檢查是否與績效詳情計數器指標關聯
檢查是否有績效詳情指標，例如 `Innodb_rows_changed`。如果計數器指標與 `io/table/sql/handler` 關聯，請遵循下列步驟：
1. 在績效詳情中，尋找說明 `io/table/sql/handler` 最高等待事件的 SQL 陳述式。如果可能，請最佳化此陳述式，以便其傳回較少的資料列。
1. 從 `schema_table_statistics` 和 `x$schema_table_statistics` 檢視中擷取最高資料表。這些檢視會顯示每個資料表所花費的時間量。如需詳細資訊，請參閱《MySQL 參考手冊》**中的 [schema\$1table\$1statistics 和 x\$1schema\$1table\$1statistics 檢視](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html)。
根據預設，資料列會依總等待時間遞減排序。具有最多爭用的資料表會最先出現。輸出指示時間是花費在讀取、寫入、提取、插入、更新，還是刪除。
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### 檢查是否有其他關聯的等待事件
如果 `synch/sxlock/innodb/btr_search_latch` 和 `io/table/sql/handler` 是造成資料庫負載異常的主因，請檢查 `innodb_adaptive_hash_index` 變數是否已開啟。若是，請考慮增加 `innodb_adaptive_hash_index_parts` 參數值。
如果自適應雜湊索引已關閉，請考慮將其開啟。若要進一步了解 MySQL 自適應雜湊索引，請參閱下列資源：
+ Percona 網站上的文章 [InnoDB 中的自適應雜湊索引是否適合我的工作負載？](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload)
+ 《MySQL 參考手冊》**中的[自適應雜湊索引](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html)
+ Percona 網站上的文章 [MySQL InnoDB 中的爭用：來自旗號區段的有用資訊](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/)
**注意**
Aurora 讀取器資料庫執行個體不支援自適應雜湊索引。
在某些情況下，當 `synch/sxlock/innodb/btr_search_latch` 和 `io/table/sql/handler` 主導時，讀取器執行個體的效能可能不佳。若是這樣，請考慮將工作負載暫時重新導向至寫入器節點，並開啟自適應雜湊索引。
# synch/cond/innodb/row\$1lock\$1wait
當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，`synch/cond/innodb/row_lock_wait` 事件便會發生。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html)。
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 3 版
## 等待時間增加的可能原因
多個資料處理語言 (DML) 陳述式正在同時存取相同的資料列。
## 動作
我們會建議不同的動作，取決於您看到的其他等待事件。
**Topics**
+ [尋找並回應負責此等待事件的 SQL 陳述式](#ams-waits.row-lock-wait.actions.id)
+ [尋找並回應封鎖工作階段](#ams-waits.row-lock-wait.actions.blocker)
### 尋找並回應負責此等待事件的 SQL 陳述式
使用績效詳情來識別負責此等待事件的 SQL 陳述式。請考慮下列策略：
+ 如果資料列鎖定是持續發生的問題，請考慮重寫應用程式以使用樂觀鎖定。
+ 使用多列陳述式。
+ 將工作負載分散到不同的資料庫物件上。您可以透過分割來執行此動作。
+ 檢查 `innodb_lock_wait_timeout` 參數的值。它控制交易在產生逾時錯誤之前等待多長時間。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 尋找並回應封鎖工作階段
判斷封鎖工作階段是閒置還是作用中。此外，了解工作階段來自應用程式還是作用中的使用者。
若要識別保留鎖定的工作階段，您可以執行 `SHOW ENGINE INNODB STATUS`。下列範例顯示範例輸出。
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
或者您可以使用下列查詢來擷取目前鎖定的詳細資訊。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
當您識別工作階段時，您的選項包括下列項目：
+ 聯絡應用程式擁有者或使用者。
+ 如果封鎖工作階段閒置，請考慮結束封鎖工作階段。此動作可能會觸發長時間回復。若要了解如何結束工作階段，請參閱 [結束工作階段或查詢](mysql-stored-proc-ending.md)。
如需識別封鎖交易的詳細資訊，請參閱 MySQL 文件中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html)。
# synch/cond/innodb/row\$1lock\$1wait\$1cond
當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，`synch/cond/innodb/row_lock_wait_cond` 事件便會發生。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)。
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版
## 等待時間增加的可能原因
多個資料處理語言 (DML) 陳述式正在同時存取相同的資料列。
## 動作
我們會建議不同的動作，取決於您看到的其他等待事件。
**Topics**
+ [尋找並回應負責此等待事件的 SQL 陳述式](#ams-waits.row-lock-wait-cond.actions.id)
+ [尋找並回應封鎖工作階段](#ams-waits.row-lock-wait-cond.actions.blocker)
### 尋找並回應負責此等待事件的 SQL 陳述式
使用績效詳情來識別負責此等待事件的 SQL 陳述式。請考慮下列策略：
+ 如果資料列鎖定是持續發生的問題，請考慮重寫應用程式以使用樂觀鎖定。
+ 使用多列陳述式。
+ 將工作負載分散到不同的資料庫物件上。您可以透過分割來執行此動作。
+ 檢查 `innodb_lock_wait_timeout` 參數的值。它控制交易在產生逾時錯誤之前等待多長時間。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 尋找並回應封鎖工作階段
判斷封鎖工作階段是閒置還是作用中。此外，了解工作階段來自應用程式還是作用中的使用者。
若要識別保留鎖定的工作階段，您可以執行 `SHOW ENGINE INNODB STATUS`。下列範例顯示範例輸出。
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
或者您可以使用下列查詢來擷取目前鎖定的詳細資訊。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
當您識別工作階段時，您的選項包括下列項目：
+ 聯絡應用程式擁有者或使用者。
+ 如果封鎖工作階段閒置，請考慮結束封鎖工作階段。此動作可能會觸發長時間回復。若要了解如何結束工作階段，請參閱 [結束工作階段或查詢](mysql-stored-proc-ending.md)。
如需識別封鎖交易的詳細資訊，請參閱 MySQL 文件中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)。
# synch/cond/sql/MDL\$1context::COND\$1wait\$1status
有執行緒正在等待資料表中繼資料鎖定時，`synch/cond/sql/MDL_context::COND_wait_status` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.cond-wait-status.context.supported)
+ [Context](#ams-waits.cond-wait-status.context)
+ [等待變多的可能原因](#ams-waits.cond-wait-status.causes)
+ [動作](#ams-waits.cond-wait-status.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
事件 `synch/cond/sql/MDL_context::COND_wait_status` 指出有執行緒正在等待資料表中繼資料鎖定。在某些情況下，一個工作階段對資料表保有中繼資料鎖定，而另一個工作階段嘗試對同一資料表取得相同的鎖定。在這類情況下，第二個工作階段會等待 `synch/cond/sql/MDL_context::COND_wait_status` 等待事件。
MySQL 使用中繼資料鎖定來管理資料庫物件的並行存取，並確保資料一致性。中繼資料鎖定適用於資料表、結構描述、排程事件、資料表空間，以及使用 `get_lock` 函數和預存程式取得的使用者鎖定。預存程式包含程序、函數和觸發程序。如需詳細資訊，請參閱 MySQL 文件中的[中繼資料鎖定](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html)。
MySQL 程序清單顯示這個工作階段處於狀態 `waiting for metadata lock` 中。在績效詳情中，如果 `Performance_schema` 已開啟，事件 `synch/cond/sql/MDL_context::COND_wait_status` 即會出現。
等待中繼資料鎖定之查詢的預設逾時是基於 `lock_wait_timeout` 參數的值，預設值為 31,536,000 秒 (365 天)。
如需有關不同 InnoDB 鎖定和可能導致衝突之鎖定類型的詳細資訊，請參閱 MySQL 文件中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)。
## 等待變多的可能原因
`synch/cond/sql/MDL_context::COND_wait_status` 事件比平時更常出現時，可能表示有效能問題，典型原因包括：
**長時間執行的交易**
一個或多個交易正在修改大量的資料，並對資料表保留鎖定很長一段時間。
**交易閒置**
一個或多個交易保持開啟狀態很長一段時間，沒有進行遞交或復原。
**大型表格上的 DDL 陳述式**
一或多個資料定義語言 (DDL) 陳述式，例如 `ALTER TABLE` 命令，已在非常大的資料表上執行。
**明確資料表鎖定**
未及時釋放的資料表上有明確的鎖定。例如，應用程式可能會不當地執行 `LOCK TABLE` 陳述式。
## 動作
我們會建議不同的動作，取決於等待事件的原因，以及 Aurora MySQL 資料庫叢集的版本。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.cond-wait-status.actions.identify)
+ [檢查是否有過去的活動](#ams-waits.cond-wait-status.actions.past-events)
+ [在 Aurora MySQL 第 2 版上執行查詢](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [回應封鎖工作階段](#ams-waits.cond-wait-status.actions.blocker)
### 識別造成事件的工作階段和查詢
您可以使用績效詳情來顯示 `synch/cond/sql/MDL_context::COND_wait_status` 等待事件所封鎖的查詢。不過，若要識別封鎖工作階段，請從資料庫叢集上的 `performance_schema` 和 `information_schema` 查詢中繼資料表。
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**尋找負責高負載的 SQL 查詢**
1. 登入 AWS 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。該資料庫執行個體的績效詳情儀表板即會出現。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行故障診斷的實用概觀，請參閱 AWS 資料庫部落格文章[使用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 檢查是否有過去的活動
您可以洞察這個等待事件，以檢查其是否發生過。若要這樣做，請完成下列動作。
+ 檢查資料處理語言 (DML) 和 DDL 輸送量和延遲，以查看工作負載是否有任何變更。
您可以使用績效詳情來尋找問題發生時等待此事件的查詢。此外，您也可以檢視接近問題發生時的查詢執行摘要。
+ 如果開啟資料庫叢集的稽核日誌或一般日誌，您可以檢查所有查詢是否在等待交易中涉及的物件 (schema.table) 上執行。您也可以檢查是否有查詢在交易之前已完成執行。
疑難排解過去事件的可用資訊有限。執行這些檢查不會顯示哪個物件正在等待資訊。不過，您可以識別事件發生時負載繁重的資料表，以及發生問題時導致衝突的常操作資料列集。然後，您可以使用此資訊，在測試環境中重現問題，並提供有關其原因的洞察。
### 在 Aurora MySQL 第 2 版上執行查詢
在 Aurora MySQL 第 2 版中，您可以查詢 `performance_schema` 資料表或 `sys` 結構描述檢視，直接識別已封鎖的工作階段。範例可說明如何查詢資料表，以識別封鎖查詢和工作階段。
在下列程序清單輸出中，連線ID `89` 正在等待中繼資料鎖定，並且正在執行 `TRUNCATE TABLE` 命令。在查詢中，於 `performance_schema` 資料表或 `sys` 結構描述檢視上，輸出會顯示封鎖工作階段是 `76`。
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
接下來，`performance_schema` 資料表或 `sys` 結構描述檢視上的查詢會顯示封鎖工作階段是 `76`。
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### 回應封鎖工作階段
當您識別工作階段時，您的選項包括下列項目：
+ 聯絡應用程式擁有者或使用者。
+ 如果封鎖工作階段閒置，請考慮結束封鎖工作階段。此動作可能會觸發長時間回復。若要了解如何結束工作階段，請參閱 [結束工作階段或查詢](mysql-stored-proc-ending.md)。
如需識別封鎖交易的詳細資訊，請參閱 MySQL 文件中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)。
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，`synch/mutex/innodb/aurora_lock_thread_slot_futex` 事件便會發生。如需詳細資訊，請參閱《MySQL 參考》**中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)。
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版
## 等待時間增加的可能原因
多個資料處理語言 (DML) 陳述式正在同時存取相同的資料列。
## 動作
我們會建議不同的動作，取決於您看到的其他等待事件。
**Topics**
+ [尋找並回應負責此等待事件的 SQL 陳述式](#ams-waits.waitsynch.actions.id)
+ [尋找並回應封鎖工作階段](#ams-waits.waitsynch.actions.blocker)
### 尋找並回應負責此等待事件的 SQL 陳述式
使用績效詳情來識別負責此等待事件的 SQL 陳述式。請考慮下列策略：
+ 如果資料列鎖定是持續發生的問題，請考慮重寫應用程式以使用樂觀鎖定。
+ 使用多列陳述式。
+ 將工作負載分散到不同的資料庫物件上。您可以透過分割來執行此動作。
+ 檢查 `innodb_lock_wait_timeout` 參數的值。它控制交易在產生逾時錯誤之前等待多長時間。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 尋找並回應封鎖工作階段
判斷封鎖工作階段是閒置還是作用中。此外，了解工作階段來自應用程式還是作用中的使用者。
若要識別保留鎖定的工作階段，您可以執行 `SHOW ENGINE INNODB STATUS`。下列範例顯示範例輸出。
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
或者您可以使用下列查詢來擷取目前鎖定的詳細資訊。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
當您識別工作階段時，您的選項包括下列項目：
+ 聯絡應用程式擁有者或使用者。
+ 如果封鎖工作階段閒置，請考慮結束封鎖工作階段。此動作可能會觸發長時間回復。若要了解如何結束工作階段，請參閱 [結束工作階段或查詢](mysql-stored-proc-ending.md)。
如需識別封鎖交易的詳細資訊，請參閱《MySQL 參考手冊》**中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)。
# synch/mutex/innodb/buf\$1pool\$1mutex
當執行緒已對 InnoDB 緩衝集區取得鎖定來存取記憶體中的頁面時，`synch/mutex/innodb/buf_pool_mutex` 事件便會發生。
**Topics**
+ [相關的引擎版本](#ams-waits.bufpoolmutex.context.supported)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [等待變多的可能原因](#ams-waits.bufpoolmutex.causes)
+ [動作](#ams-waits.bufpoolmutex.actions)
## 相關的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版
## Context
`buf_pool` 互斥是單一互斥，其會保護緩衝集區的控制資料結構。
如需詳細資訊，請參閱 MySQL 文件中的[使用效能結構描述監控 InnoDB 互斥等待](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)。
## 等待變多的可能原因
這是工作負載特定的等待事件。`synch/mutex/innodb/buf_pool_mutex` 出現在最高等待事件之間的常見原因包括：
+ 緩衝集區不夠大，無法容納工作資料集。
+ 工作負載更特定於來自資料庫中特定資料表的特定頁面，從而導致緩衝集區中的爭用。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.bufpoolmutex.actions.identify)
+ [使用績效詳情](#ams-waits.bufpoolmutex.actions.action1)
+ [建立 Aurora 複本](#ams-waits.bufpoolmutex.actions.action2)
+ [檢查緩衝集區大小](#ams-waits.bufpoolmutex.actions.action3)
+ [監控全域狀態歷史記錄](#ams-waits.bufpoolmutex.actions.action4)
### 識別造成事件的工作階段和查詢
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**在 AWS 管理主控台中檢視最高 SQL 圖表**
1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在 **Database load** (資料庫負載) 圖表下方，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 使用績效詳情
此事件與工作負載相關。您可以使用績效詳情執行下列動作：
+ 從應用程式日誌或相關來源識別等待事件開始的時間，以及工作負載在該段時間是否有任何變更。
+ 識別負責此等待事件的 SQL 陳述式。檢查查詢的執行計劃，以確定這些查詢已最佳化，並使用適當的索引。
如果負責等待事件的最高查詢與相同的資料庫物件或資料表相關，請考慮分割該物件或資料表。
### 建立 Aurora 複本
您可以建立 Aurora 複本來提供唯讀流量。您也可以使用 Aurora Auto Scaling 來處理讀取流量的突增。務必在 Aurora 複本上執行排定的唯讀任務和邏輯備份。
如需更多詳細資訊，請參閱 [使用 Amazon Aurora 自動擴展搭配 Aurora 複本](Aurora.Integrating.AutoScaling.md)。
### 檢查緩衝集區大小
查看指標 `innodb_buffer_pool_wait_free`，檢查緩衝集區大小是否足以處理工作負載。如果此指標的值很高且持續增加，這表示緩衝集區的大小不足以處理工作負載。如果 `innodb_buffer_pool_size` 已正確設定，則 `innodb_buffer_pool_wait_free` 的值應該很小。如需詳細資訊，請參閱 MySQL 文件中的 [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free)。
如果資料庫執行個體具有足夠的記憶體，可供工作階段緩衝區和作業系統任務使用，請增加緩衝區集區大小。如果沒有，請將資料庫執行個體變更為較大的資料庫執行個體類別，以取得可配置給緩衝集區的額外記憶體。
**注意**
Aurora MySQL 會根據設定的 `innodb_buffer_pool_size` 自動調整 `innodb_buffer_pool_instances` 的值。
### 監控全域狀態歷史記錄
透過監控狀態變數的變更率，您可以在資料庫執行個體上偵測鎖定或記憶體問題。開啟全域狀態歷史記錄 (GoSH)，如果尚未開啟的話。如需 GoSh 的詳細資訊，請參閱[管理全域狀態歷史記錄](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)。
您也可以建立自訂 Amazon CloudWatch 指標來監控狀態變數。如需詳細資訊，請參閱[發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
# synch/mutex/innodb/fil\$1mutex
當工作階段正在等待存取資料表空間記憶體快取時，`synch/mutex/innodb/fil_system_mutex` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Context](#ams-waits.innodb-fil-system-mutex.context)
+ [等待變多的可能原因](#ams-waits.innodb-fil-system-mutex.causes)
+ [動作](#ams-waits.innodb-fil-system-mutex.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
InnoDB 會使用資料表空間來管理資料表和日誌檔案的儲存區域。「資料表空間記憶體快取」**是全域記憶體結構，用於維護資料表空間的相關資訊。MySQL 會使用 `synch/mutex/innodb/fil_system_mutex` 等待來控制資料表空間記憶體快取的並行存取。
事件 `synch/mutex/innodb/fil_system_mutex` 指出目前有一個以上的作業需要擷取和操控相同資料表空間之資料表空間記憶體快取中的資訊。
## 等待變多的可能原因
`synch/mutex/innodb/fil_system_mutex` 事件比平時更常出現時，可能表示有效能問題，這通常發生在下列所有情況都存在時：
+ 更新或刪除同一資料表中資料的並行資料處理語言 (DML) 作業增加。
+ 此資料表的資料表空間非常大，並有許多資料頁面。
+ 這些資料頁面的填滿係數很低。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [在離峰時間重組大型資料表](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 識別造成事件的工作階段和查詢
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，請檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**尋找負責高負載的 SQL 查詢**
1. 登入 AWS 管理主控台 ，並在 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)：// 開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。該資料庫執行個體的績效詳情儀表板即會出現。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
了解哪些查詢導致大量 `synch/mutex/innodb/fil_system_mutex` 等待的另一種方法是檢查 `performance_schema`，如下列範例所示。
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### 在離峰時間重組大型資料表
在生產時間以外的維護時段期間，重組您識別為大量 `synch/mutex/innodb/fil_system_mutex` 等待事件之來源的大型資料表。這樣做可確保內部資料表空間映射清除不會在快速存取資料表至關重要時發生。如需重組資料表的相關資訊，請參閱《MySQL 參考》**中的 [OPTIMIZE TABLE 陳述式](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html)。
# synch/mutex/innodb/fil\$1mutex
由於大量交易而有高資料庫活動時，`synch/mutex/innodb/trx_sys_mutex` 事件便會發生。
**Topics**
+ [相關的引擎版本](#ams-waits.trxsysmutex.context.supported)
+ [Context](#ams-waits.trxsysmutex.context)
+ [等待變多的可能原因](#ams-waits.trxsysmutex.causes)
+ [動作](#ams-waits.trxsysmutex.actions)
## 相關的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
在內部，InnoDB 資料庫引擎會使用可重複讀取隔離層級搭配快照，來提供讀取一致性。這可為您提供在建立快照時資料庫的時間點檢視。
在 InnoDB 中，所有變更一到達就會套用到資料庫，無論是否已遞交它們。這種方法表示，若沒有多版本並行控制 (MVCC)，連線到資料庫的所有使用者都會看到所有的變更和最新的資料列。因此，InnoDB 需要一種方法來追蹤變更，以了解在必要時要復原什麼。
若要這樣做，InnoDB 會使用交易系統 (`trx_sys`) 來追蹤快照。交易系統會執行下列動作：
+ 追蹤復原日誌中每個資料列的交易 ID。
+ 使用名為 `ReadView` 的內部 InnoDB 結構，其有助於識別快照可以看到哪些交易 ID。
## 等待變多的可能原因
以一致且受控方式處理 (建立、讀取、更新和刪除) 交易 ID 的任何資料庫作業都會從 `trx_sys` 產生對互斥的呼叫。
這些呼叫發生在三個函數內：
+ `trx_sys_mutex_enter` – 建立互斥。
+ `trx_sys_mutex_exit` – 釋放互斥。
+ `trx_sys_mutex_own` – 測試是否擁有互斥。
InnoDB 效能結構描述檢測會追蹤所有 `trx_sys` 互斥呼叫。追蹤包括但不限於在資料庫啟動或關閉時管理 `trx_sys`、復原作業、復原清除、資料列讀取存取，以及緩衝集區載入。具有大量交易的高資料庫活動會導致 `synch/mutex/innodb/trx_sys_mutex` 出現在最高等待事件之間。
如需詳細資訊，請參閱 MySQL 文件中的[使用效能結構描述監控 InnoDB 互斥等待](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.trxsysmutex.actions.identify)
+ [檢查其他等待事件](#ams-waits.trxsysmutex.actions.action1)
### 識別造成事件的工作階段和查詢
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看導致最高負載的等待事件。了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
**檢視 AWS 管理主控台 中的最高 SQL 圖表**
1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在 **Database load** (資料庫負載) 圖表下，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 檢查其他等待事件
檢查與 `synch/mutex/innodb/trx_sys_mutex` 等待事件相關聯的其他等待事件。執行此動作可提供工作負載本質的詳細資訊。大量的交易可能會減少輸送量，但工作負載也可能使此變得必要。
如需如何最佳化交易的詳細資訊，請參閱 MySQL 文件中的[最佳化 InnoDB 交易管理](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)。
# synch/sxlock/innodb/hash\$1table\$1locks
當緩衝集區中找不到的頁面必須從儲存體讀取時，`synch/sxlock/innodb/hash_table_locks` 事件便會發生。
**Topics**
+ [支援的引擎版本](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Context](#ams-waits.sx-lock-hash-table-locks.context)
+ [等待變多的可能原因](#ams-waits.sx-lock-hash-table-locks.causes)
+ [動作](#ams-waits.sx-lock-hash-table-locks.actions)
## 支援的引擎版本
下列版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版
## Context
事件 `synch/sxlock/innodb/hash_table_locks` 指出工作負載經常存取未存放在緩衝集區中的資料。此等待事件與新的頁面新增相關，而且舊資料會從緩衝集區移出。存放在緩衝集區的資料過時，而且新資料必須進行快取，因此會將過時頁面移出，以允許快取新頁面。MySQL 會使用最近最少使用 (LRU) 演算法，從緩衝集區移出頁面。工作負載嘗試存取尚未載入至緩衝集區的資料或已從緩衝集區移出的資料。
當工作負載必須存取磁碟上檔案中的資料，或從緩衝集區的 LRU 清單釋放區塊，或將區塊新增至其中時，此等待事件便會發生。這些作業等待取得共用的排除鎖定 (SX-lock)。此 SX-lock 用於透過「雜湊表」**進行同步，此雜湊表是記憶體中的資料表，旨在改善緩衝集區存取效能。
如需詳細資訊，請參閱 MySQL 文件中的[緩衝集區](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html)。
## 等待變多的可能原因
`synch/sxlock/innodb/hash_table_locks` 等待事件比平時更常出現時，可能表示有效能問題，典型原因包括：
**緩衝集區大小過小**
緩衝集區的大小太小，無法將所有經常存取的頁面保留在記憶體中。
**工作負載繁重**
工作負載導致頻繁的移出，並在緩衝區快取中重新載入資料頁面。
**讀取頁面時發生錯誤**
讀取緩衝集區中的頁面時發生錯誤，這可能表示資料損毀。
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [增加緩衝集區的大小](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [改善資料存取模式](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [減少或避免完整資料表掃描](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [檢查錯誤日誌是否有頁面毀損](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### 增加緩衝集區的大小
確定緩衝集區已適當地調整為適合工作負載的大小。若要這樣做，您可以檢查緩衝區快取命中率。通常，如果值低於 95%，請考慮增加緩衝集區大小。越大的緩衝集區可以將經常存取的頁面保留在記憶體中的時間越長 若要增加緩衝集區的大小，請修改 `innodb_buffer_pool_size` 參數的值。此參數的預設值是基於資料庫執行個體類別大小。如需詳細資訊，請參閱 [Amazon Aurora MySQL 資料庫組態的最佳實務](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/)。
### 改善資料存取模式
檢查受此等待及其執行計劃影響的查詢。考慮改善資料存取模式。例如，如果您是使用 [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php)，則可以嘗試增加陣列擷取大小。
您可以使用績效詳情來顯示可能造成 `synch/sxlock/innodb/hash_table_locks` 等待事件的查詢和工作階段。
**尋找負責高負載的 SQL 查詢**
1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。
1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。
1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。
1. 在頁面底端，選擇 **Top SQL** (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱 AWS 資料庫部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。
### 減少或避免完整資料表掃描
監控工作負載，以查看它是否正在執行完整資料表掃描，若是，請減少或避免它們。例如，您可以監控狀態變數，例如 `Handler_read_rnd_next`。如需詳細資訊，請參閱 MySQL 文件中的[伺服器狀態變數](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next)。
### 檢查錯誤日誌是否有頁面毀損
你可以檢查 mysql-error.log，是否在接近問題發生時偵測到毀損相關訊息。您可以用來解決問題的訊息位於錯誤日誌中。您可能需要重新建立已報告為毀損的物件。
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
當工作階段正在等待取得互斥以管理工作階段暫存資料表空間集區時，會發生`synch/mutex/innodb/temp_pool_manager_mutex`等待事件。
**Topics**
+ [支援的引擎版本](#ams-waits.io-temppoolmanager.context.supported)
+ [Context](#ams-waits.io-temppoolmanager.context)
+ [等待時間增加的可能原因](#ams-waits.io-temppoolmanager.causes)
+ [動作](#ams-waits.io-temppoolmanager.actions)
## 支援的引擎版本
下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 3 版
## Context
Aurora MySQL 3.x 版和更新版本使用 `temp_pool_manager_mutex` 來控制同時存取暫存資料表空間集區的多個工作階段。Aurora MySQL 透過 Aurora 叢集磁碟區管理持久性資料儲存，以及管理暫存檔案的本機儲存。當工作階段在 Aurora 叢集磁碟區上建立暫存資料表時，需要暫存資料表空間。
當工作階段第一次請求暫存資料表空間時，MySQL 會從共用集區配置工作階段暫存資料表空間。對於下列資料表類型，工作階段一次最多可保留 2 個暫存資料表空間：
+ 使用者建立的暫存資料表
+ Optimizer 產生的內部暫時資料表
預設`TempTable`引擎使用下列溢位機制來處理暫存資料表：
+ 將資料表存放在 RAM 中，最多可達 [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)限制。
+ 當 RAM 已滿時，移至本機儲存體上的記憶體映射檔案。
+ 當記憶體映射檔案達到其[https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap)限制時，使用共用叢集磁碟區。
暫存資料表超過 RAM 和本機儲存限制後，MySQL 會使用磁碟上資料表空間來管理它們。
當工作階段需要磁碟上暫存資料表時，MySQL：
+ 尋找集區中要重複使用的可用`INACTIVE`資料表空間。
+ 如果沒有`INACTIVE`空格，則建立新的 10 個資料表空間。
當工作階段中斷連線時，MySQL：
+ 截斷工作階段的暫存資料表空間。
+ 在集區中將其標記為非作用中以重複使用。
+ 維護目前的集區大小，直到伺服器重新啟動為止。
+ 重新啟動後，返回預設集區大小 (10 個資料表空間）。
## 等待時間增加的可能原因
導致此等待事件的常見情況：
+ 在叢集磁碟區上建立內部暫存資料表的並行工作階段。
+ 在叢集磁碟區上建立使用者暫存資料表的並行工作階段。
+ 使用作用中資料表空間突然終止工作階段。
+ 大量寫入工作負載期間的資料表空間集區擴展。
+ 並行查詢存取 `INFORMATION_SCHEMA.`
## 動作
根據等待事件的原因，我們會建議不同的動作。
**Topics**
+ [監控和最佳化暫存資料表用量](#ams-waits.io-temppoolmanager.actions.monitor)
+ [使用 INFORMATION\$1SCHEMA 檢閱查詢](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [增加 innodb\$1sync\$1array\$1size 參數](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [實作連線集區](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### 監控和最佳化暫存資料表用量
若要監控和最佳化暫存資料表用量，請使用下列其中一種方法：
+ 檢查績效詳情中的`Created_tmp_disk_tables`計數器，以追蹤整個 Aurora 叢集的磁碟上暫存資料表建立。
+ 在資料庫中執行此命令，以直接監控暫存資料表的建立：`mysql> show status like '%created_tmp_disk%'`。
**注意**
Aurora MySQL 讀取器節點和寫入器節點之間的暫時資料表行為不同。如需詳細資訊，請參閱[Aurora MySQL 第 3 版的新暫時資料表行為](ams3-temptable-behavior.md)。
識別建立暫存資料表的查詢之後，請採取下列最佳化步驟：
+ 使用 `EXPLAIN` 檢查查詢執行計劃，並識別建立暫存資料表的位置和原因。
+ 盡可能修改查詢以減少暫時資料表用量。
如果僅查詢最佳化無法解決效能問題，請考慮調整這些組態參數：
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram)- 控制暫存資料表的 RAM 用量上限。
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) - 設定記憶體映射檔案儲存的限制。
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size)- 啟用 `aurora_tmptable_enable_per_table_limit` 時套用 （預設為停用）。
**重要**
請注意，無論組態設定為何，某些查詢條件一律需要磁碟上暫存資料表。如需詳細資訊`TempTable`，請參閱[在 Amazon RDS for MySQL 和 Amazon Aurora MySQL 上使用 TempTable 儲存引擎](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)。
### 使用 INFORMATION\$1SCHEMA 檢閱查詢
當您查詢`INFORMATION_SCHEMA`資料表時，MySQL 會在叢集磁碟區上建立 InnoDB 暫存資料表。每個工作階段都需要這些資料表的暫時資料表空間，這可能會在高並行存取期間導致效能問題。
若要改善效能：
+ `INFORMATION_SCHEMA` 盡可能使用 `PERFORMANCE_SCHEMA`而非 。
+ 如果您必須使用 `INFORMATION_SCHEMA`，請減少執行這些查詢的頻率。
### 增加 innodb\$1sync\$1array\$1size 參數
`innodb_sync_array_size` 參數控制 MySQL 中互斥/鎖定等待陣列的大小。的預設值`1`適用於一般工作負載，但增加預設值可以減少高並行期間的執行緒爭用。
當您的工作負載顯示等待執行緒數量增加時：
+ 監控工作負載中等待執行緒的數量。
+ 將 設定為`innodb_sync_array_size`等於或高於執行個體的 vCPU 計數，以分割執行緒協調結構並減少爭用。
**注意**
若要判斷 RDS 執行個體上可用的 vCPUs 數量，請參閱 [Amazon RDS 執行個體類型 ](https://aws.amazon.com/rds/instance-types/)中的 vCPU 規格。
### 實作連線集區
MySQL 會將專用資料表空間指派給建立暫存資料表的每個工作階段。此資料表空間會保持作用中狀態，直到資料庫連線結束為止。若要更有效率地管理您的 資源：
+ 實作連線集區以限制作用中暫存資料表空間的數量。
+ 重複使用現有的連線，而不是為每個操作建立新的連線。
# 使用執行緒狀態調校 Aurora MySQL
下表彙總了 Aurora MySQL 最常見的一般執行緒狀態。
| 一般執行緒狀態 | 描述 |
| --- | --- |
| [正在建立排序索引](ams-states.sort-index.md) | 此執行緒狀態指出執行緒正在處理 `SELECT` 陳述式，而此陳述式需要使用內部暫時資料表來排序資料。 |
| [正在傳送資料](ams-states.sending-data.md) | 此執行緒狀態指出執行緒正在讀取和篩選查詢的資料列，以決定正確的結果集。 |
# 正在建立排序索引
`creating sort index` 執行緒狀態指出執行緒正在處理 `SELECT` 陳述式，而此陳述式需要使用內部暫時資料表來排序資料。
**Topics**
+ [支援的引擎版本](#ams-states.sort-index.context.supported)
+ [Context](#ams-states.sort-index.context)
+ [等待變多的可能原因](#ams-states.sort-index.causes)
+ [動作](#ams-states.sort-index.actions)
## 支援的引擎版本
下列版本支援這個執行緒狀態資訊：
+ Aurora MySQL 第 2 版，最高至 2.09.2
## Context
當具有 `ORDER BY` 或 `GROUP BY` 子句的查詢無法使用現有的索引來執行作業時，`creating sort index` 狀態便會出現。在此情況下，MySQL 需要執行更昂貴的 `filesort` 作業。如果結果集不太大，此作業通常會在記憶體中執行。否則，它涉及在磁碟上建立檔案。
## 等待變多的可能原因
出現 `creating sort index` 本身並不表示有問題。如果效能不佳，並且您經常看到 `creating sort index` 的執行個體，最可能的原因是搭配 `ORDER BY` 或 `GROUP BY` 運算子的慢速查詢。
## 動作
一般指導方針是尋找搭配 `ORDER BY` 或 `GROUP BY` 子句的查詢，這些子句與 `creating sort index` 狀態中的增加相關聯。然後查看新增索引或增加排序緩衝區大小是否可以解決問題。
**Topics**
+ [如果未開啟效能結構描述，請將其開啟](#ams-states.sort-index.actions.enable-pfs)
+ [識別問題查詢](#ams-states.sort-index.actions.identify)
+ [檢查說明計劃以取得檔案排序使用情形](#ams-states.sort-index.actions.plan)
+ [增加排序緩衝區大小](#ams-states.sort-index.actions.increasebuffersize)
### 如果未開啟效能結構描述，請將其開啟
只在效能結構描述檢測未開啟時，績效詳情才會報告執行緒狀態。當效能結構描述檢測開啟時，績效詳情會改為報告等待事件。效能結構描述檢測會在您調查潛在的效能問題時提供其他洞察和更好的工具。因此，建議您開啟效能結構描述。如需詳細資訊，請參閱[Aurora MySQL 上 Performance Insights 的效能結構描述概觀](USER_PerfInsights.EnableMySQL.md)。
### 識別問題查詢
若要識別目前哪些查詢正在造成 `creating sort index` 狀態中的增加，請執行 `show processlist` 並查看是否有任何查詢具有 `ORDER BY` 或 `GROUP BY`。選擇性地執行 `explain for connection N`，其中 `N` 是搭配 `filesort` 之查詢的程序清單 ID。
若要識別過去哪些查詢造成這些增加，請開啟慢速查詢日誌，並尋找搭配 `ORDER BY` 的查詢。對慢速查詢執行 `EXPLAIN`，並尋找「使用檔案排序」。如需詳細資訊，請參閱[檢查說明計劃以取得檔案排序使用情形](#ams-states.sort-index.actions.plan)。
### 檢查說明計劃以取得檔案排序使用情形
識別哪些陳述式搭配導致 `creating sort index` 狀態的 `ORDER BY` 或 `GROUP BY` 子句。
下列範例顯示如何對查詢執行 `explain`：`Extra` 資料欄顯示此查詢使用 `filesort`。
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2064548
filtered: 100.00
Extra: Using filesort
1 row in set, 1 warning (0.01 sec)
```
下列範例顯示在資料欄 `c1` 上建立索引之後對同一查詢執行 `EXPLAIN` 的結果。
```
mysql> alter table mytable add index (c1);
```
```
mysql> explain select * from mytable order by c1 limit 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: mytable
partitions: NULL
type: index
possible_keys: NULL
key: c1
key_len: 1023
ref: NULL
rows: 10
filtered: 100.00
Extra: Using index
1 row in set, 1 warning (0.01 sec)
```
如需使用索引進行排序最佳化的相關資訊，請參閱 MySQL 文件中的 [Orice By 最佳化](https://dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html)。
### 增加排序緩衝區大小
若要查看特定查詢是否需要已在磁碟上建立檔案的 `filesort` 程序，請在執行查詢之後檢查 `sort_merge_passes` 變數值。下列顯示一個範例。
```
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
--- run query
mysql> select * from mytable order by u limit 10;
--- run status again:
mysql> show session status like 'sort_merge_passes';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Sort_merge_passes | 0 |
+-------------------+-------+
1 row in set (0.01 sec)
```
如果 `sort_merge_passes` 的值很高，請考慮增加排序緩衝區大小。在工作階段層級套用增加，因為全域增加它可以大幅地增加 RAM MySQL 使用數量。下列範例顯示如何在執行查詢之前變更排序緩衝區大小。
```
mysql> set session sort_buffer_size=10*1024*1024;
Query OK, 0 rows affected (0.00 sec)
-- run query
```
# 正在傳送資料
`sending data` 執行緒狀態表示執行緒正在讀取和篩選查詢的資料列，以決定正確的結果集。名稱產生誤導，因為它暗示狀態正在傳輸資料，而不是收集和準備稍後傳送的資料。
**Topics**
+ [支援的引擎版本](#ams-states.sending-data.context.supported)
+ [Context](#ams-states.sending-data.context)
+ [等待變多的可能原因](#ams-states.sending-data.causes)
+ [動作](#ams-states.sending-data.actions)
## 支援的引擎版本
下列版本支援這個執行緒狀態資訊：
+ Aurora MySQL 第 2 版，最高至 2.09.2
## Context
許多執行緒狀態是短暫的。`sending data` 期間發生的作業傾向於執行大量磁碟或快取讀取。因此，`sending data` 通常是執行時間最長的狀態，涵蓋給定查詢的生命週期。當 Aurora MySQL 執行下列動作時，此狀態便會出現：
+ 讀取和處理 `SELECT` 陳述式的資料列
+ 從磁碟或記憶體執行大量讀取
+ 從特定查詢中完成所有資料的完整讀取
+ 從資料表、索引或預存程序的工作中讀取資料
+ 排序、分組或排序資料
在 `sending data` 狀態完成準備資料之後，執行緒狀態 `writing to net` 指出資料傳回至用戶端。通常，只在結果集非常大或嚴重的網路延遲正在減慢傳輸速度時，才會擷取 `writing to net`。
## 等待變多的可能原因
出現 `sending data` 本身並不表示有問題。如果效能不佳，並且您經常看到 `sending data` 的執行個體，最可能的原因如下。
**Topics**
+ [無效率查詢](#ams-states.sending-data.causes.structure)
+ [次佳伺服器組態](#ams-states.sending-data.causes.server)
### 無效率查詢
在大多數情況下，應對此狀態負責的是未使用適當的索引來尋找特定查詢之結果集的查詢。例如，考慮一個查詢，其為加州所有訂單讀取 1,000 萬筆記錄資料表，其中狀態資料行未建立索引或未好好建立索引。在後者情況下，索引可能存在，但最佳化工具由於低基數而忽略它。
### 次佳伺服器組態
如果數個查詢出現在 `sending data` 狀態中，則可能未好好設定資料庫伺服器。尤其，伺服器可能有下列問題：
+ 資料庫伺服器沒有足夠的運算容量：磁碟輸入/輸出、磁碟類型和速度、CPU 或 CPU 數量。
+ 伺服器缺乏配置的資源，例如 InnoDB 資料表的 InnoDB 緩衝集區或 MyISAM 資料表的索引鍵緩衝區。
+ 每個執行緒記憶體設定 (例如 `sort_buffer`、`read_buffer` 和 `join_buffer`) 都會耗用比所需還要多的 RAM，因而使實體伺服器缺乏記憶體資源。
## 動作
一般指導方針是檢查效能結構描述來尋找傳回大量資料列的查詢。如果不使用索引的記錄查詢已開啟，您也可以檢查來自慢速日誌的結果。
**Topics**
+ [如果未開啟效能結構描述，請將其開啟](#ams-states.sending-data.actions.enable-pfs)
+ [檢查記憶體設定](#ams-states.sending-data.actions.memory)
+ [檢查說明計劃以取得索引使用情形](#ams-states.sending-data.actions.plans)
+ [檢查傳回的資料量](#ams-states.sending-data.actions.maintenance)
+ [檢查是否有並行問題](#ams-states.sending-data.actions.concurrent-queries)
+ [檢查請求的結構](#ams-states.sending-data.actions.subqueries)
### 如果未開啟效能結構描述，請將其開啟
只在效能結構描述檢測未開啟時，績效詳情才會報告執行緒狀態。當效能結構描述檢測開啟時，績效詳情會改為報告等待事件。效能結構描述檢測會在您調查潛在的效能問題時提供其他洞察和更好的工具。因此，建議您開啟效能結構描述。如需詳細資訊，請參閱[Aurora MySQL 上 Performance Insights 的效能結構描述概觀](USER_PerfInsights.EnableMySQL.md)。
### 檢查記憶體設定
檢查主要緩衝集區的記憶體設定。確定這些集區已適當地調整為適合工作負載的大小。如果您的資料庫使用多個緩衝集區執行個體，請確定它們不會分成許多小型緩衝集區。資料表一次只能使用一個緩衝集區。
請確定下列用於每個執行緒的記憶體設定，其大小適當：
+ read\$1buffer
+ read\$1rnd\$1buffer
+ sort\$1buffer
+ join\$1buffer
+ binlog\$1cache
除非您有修改設定的特定原因，否則請使用預設值。
### 檢查說明計劃以取得索引使用情形
對於處於 `sending data` 執行緒狀態的查詢，請檢查計劃，以判斷是否使用適當的索引。如果查詢未使用有用的索引，請考慮新增 `USE INDEX` 或 `FORCE INDEX` 之類的提示。提示可大幅增加或減少執行查詢所需的時間，因此在新增它們之前請小心。
### 檢查傳回的資料量
檢查正在查詢的資料表，以及它們包含的資料量。可以封存此資料的任何一個嗎？ 在許多情況下，查詢執行時間不佳的原因不是查詢計劃的結果，而是要處理的資料量。許多開發人員在將資料新增到資料庫時非常有效率，但在設計和開發階段很少考慮資料集生命週期。
尋找在低容量資料庫中表現良好，但在目前系統中表現不佳的查詢。有時設計特定查詢的開發人員可能無法意識到這些查詢正在傳回 350,000 個資料列。開發人員可能已在較低容量環境 (其具有的資料集比生產環境具有的還要小) 開發了查詢。
### 檢查是否有並行問題
檢查相同類型的多個查詢是否同時執行。某些形式的查詢在單獨執行時可以有效地執行。不過，如果類似形式的查詢一起執行或大量執行，它們可能會導致並發問題。通常，當資料庫使用暫時資料表來呈現結果時，就會造成這些問題。限制性交易隔離層級也可能會導致並行問題。
如果同時讀取和寫入至資料表，則資料庫可能正在使用鎖定。若要協助識別效能不佳的期間，請透過大規模的批次程序檢查資料庫的使用情形。若要查看最近的鎖定和回復，請檢查 `SHOW ENGINE INNODB STATUS` 命令的輸出。
### 檢查請求的結構
檢查從這些狀態擷取的查詢是否使用子查詢。這種類型的查詢通常會導致效能不佳，因為資料庫會在內部編譯結果，然後將它們代入查詢以呈現資料。此程序是資料庫的額外步驟。在許多情況下，這個步驟可能會在高度並行載入條件中造成不佳的效能。
亦請檢查您的查詢是否使用大量的 `ORDER BY` 和 `GROUP BY` 子句。在這類操作中，通常資料庫必須首先在記憶體中形成整個資料集。然後，必須在將其傳送至用戶端之前以特定方式將其排序或分組。
# 使用 Amazon DevOps Guru 主動洞察，調校 Aurora MySQL
DevOps Guru 主動洞察會在 Aurora MySQL 資料庫叢集上的異常狀況發生之前，即偵測到這些問題。DevOps Guru 可以執行下列動作：
+ 透過交叉檢查一般建議設定與您的資料庫設定，避免許多常見的資料庫問題。
+ 警告您機群內的重大問題，若未勾選，可能導致更嚴重的問題。
+ 提醒您新發現的問題。
每個主動洞察都包含問題原因分析和修正動作建議。
**Topics**
+ [InnoDB 歷史記錄清單長度顯著增加](proactive-insights.history-list.md)
+ [資料庫正在磁碟上建立暫存資料表](proactive-insights.temp-tables.md)
# InnoDB 歷史記錄清單長度顯著增加
從*日期*到 *db-instance* 的*長度*，針對資料列變更的歷史記錄清單長度皆顯著增加。這會影響查詢和資料庫關閉效能。
**Topics**
+ [支援的引擎版本](#proactive-insights.history-list.context.supported)
+ [Context](#proactive-insights.history-list.context)
+ [造成此問題的可能原因](#proactive-insights.history-list.causes)
+ [動作](#proactive-insights.history-list.actions)
+ [相關指標](#proactive-insights.history-list.metrics)
## 支援的引擎版本
所有版本的 Aurora MySQL 都支援此洞察資訊。
## Context
InnoDB 交易系統會維護多版本並行控制 (MVCC)。修改資料列時，修改前的版本會在還原日誌中儲存為還原記錄。每個還原記錄都有對先前重做記錄的參照，進而形成一份連結清單。
InnoDB 歷史記錄清單是已提交交易的還原記錄全域清單。交易不再需要歷史記錄時，MySQL 會用歷史記錄清單來清除記錄和日誌頁面。歷史記錄清單長度是清單中所有修改項目的還原記錄總數。每個日誌都包含一個或多個修改項目。若 InnoDB 歷史記錄清單長度太長，表示該清單具有過多舊資料列版本，導致查詢和資料庫關閉變慢。
## 造成此問題的可能原因
歷史記錄清單過長的典型原因包括：
+ 長時間執行的交易 (讀取或寫入)
+ 繁重的寫入負載
## 動作
根據洞察的原因，我們會建議不同的動作。
**Topics**
+ [在 InnoDB 歷史記錄清單減少之前，請不要開始任何涉及資料庫關閉的操作](#proactive-insights.history-list.actions.no-shutdown)
+ [找出並關閉長時間執行的交易](#proactive-insights.history-list.actions.long-txn)
+ [使用績效詳情，找出最高主機和最高使用者。](#proactive-insights.history-list.actions.top-PI)
### 在 InnoDB 歷史記錄清單減少之前，請不要開始任何涉及資料庫關閉的操作
InnoDB 歷史記錄清單過長會降低資料庫關閉速度，因此請在啟動涉及資料庫關閉的操作之前減少清單大小。這些操作包括主要版本資料庫升級。
### 找出並關閉長時間執行的交易
您可以透過查詢 `information_schema.innodb_trx`，找出長時間執行的交易。
**注意**
也請務必在僅供讀取複本上尋找長時間執行的交易。
**若要找出並關閉長時間執行的交易**
1. 在您的 SQL 用戶端執行下列查詢：
```
SELECT a.trx_id,
a.trx_state,
a.trx_started,
TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open",
a.trx_rows_modified,
b.USER,
b.host,
b.db,
b.command,
b.time,
b.state
FROM information_schema.innodb_trx a,
information_schema.processlist b
WHERE a.trx_mysql_thread_id=b.id
AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10
ORDER BY trx_started
```
1. 使用預存程序 [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) 結束每個長時間執行的交易。
### 使用績效詳情，找出最高主機和最高使用者。
最佳化交易，以立即遞交大量已修改的資料列。
## 相關指標
下列指標與此洞察相關：
+ `trx_rseg_history_len` – 您可以在績效詳情和 `INFORMATION_SCHEMA.INNODB_METRICS` 資料表中檢視此計數器指標。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB INFORMATION\$1SCHEMA 指標資料表](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-metrics-table.html)。
+ `RollbackSegmentHistoryListLength` – 此 Amazon CloudWatch 指標會衡量記錄具有刪除標記記錄之已遞交交易的復原日誌。這些記錄已排程由 InnoDB 清除操作處理。指標 `trx_rseg_history_len` 具有與 `RollbackSegmentHistoryListLength` 相同的值。
+ `PurgeBoundary` – 允許 InnoDB 清除的交易編號上限。如果此 CloudWatch 指標長時間沒有推進，則表示 InnoDB 清除被長時間執行的交易封鎖。若要調查，請檢查 Aurora MySQL 資料庫叢集上的作用中交易。此指標僅適用於 Aurora MySQL 2.11 版及更高版本，以及 3.08 版及更高版本。
+ `PurgeFinishedPoint` – 執行 InnoDB 清除的交易編號上限。此 CloudWatch 指標可協助您檢查進行 InnoDB 清除的速度。此指標僅適用於 Aurora MySQL 2.11 版及更高版本，以及 3.08 版及更高版本。
+ `TransactionAgeMaximum` – 最舊作用中執行交易的存留期。此 CloudWatch 指標僅適用於 Aurora MySQL 3.08 版及更高版本。
+ `TruncateFinishedPoint` – 執行復原截斷的交易編號上限。此 CloudWatch 指標僅適用於 Aurora MySQL 2.11 版及更高版本，以及 3.08 版及更高版本。
如需 CloudWatch 指標的相關資訊，請參閱 [Amazon Aurora 的執行個體層級指標](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)。
# 資料庫正在磁碟上建立暫存資料表
您最近的磁碟上暫存資料表用量大幅增加，已達*百分比*。資料庫現在每秒建立約*數量*份暫存資料表。這可能會影響 *db-instance* 的效能並增加磁碟操作。
**Topics**
+ [支援的引擎版本](#proactive-insights.temp-tables.context.supported)
+ [Context](#proactive-insights.temp-tables.context)
+ [造成此問題的可能原因](#proactive-insights.temp-tables.causes)
+ [動作](#proactive-insights.temp-tables.actions)
+ [相關指標](#proactive-insights.temp-tables.metrics)
## 支援的引擎版本
所有版本的 Aurora MySQL 都支援此洞察資訊。
## Context
有時候，MySQL 伺服器需要在處理查詢時建立內部暫存資料表。Aurora MySQL 可以在記憶體中保存內部暫存資料表。可以由 Temptable 或 MEMORY 儲存引擎處理，或由 InnoDB 儲存在磁碟上。如需詳細資訊，請參閱《MySQL 參考手冊》**中的 [MySQL 中的內部暫存資料表使用](https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html)。
## 造成此問題的可能原因
磁碟上暫存資料表數量增加，表示有使用複雜的查詢。若所設記憶體不足以將暫存資料表儲存在記憶體， Aurora MySQL 會在磁碟上建立資料表。這可能會影響效能並增加磁碟操作。
## 動作
根據洞察的原因，我們會建議不同的動作。
+ 針對 Aurora MySQL 第 3 版，建議您使用 TempTable 儲存引擎。
+ 只選取必要欄，以最佳化查詢，傳回較少的資料。
若您在啟用並計時所有 `statement` 工具的情況下開啟效能結構描述，您可以查詢 `SYS.statements_with_temp_tables`，以擷取使用暫存資料表的查詢清單。如需詳細資訊，請參閱 MySQL 文件中的[使用 sys 結構描述的先決條件](https://dev.mysql.com/doc/refman/8.0/en/sys-schema-prerequisites.html)。
+ 考慮涉及排序和分組操作的索引欄。
+ 重寫查詢以避免 `BLOB` 和 `TEXT` 欄。這些欄始終使用磁碟。
+ 調校下列資料庫參數：`tmp_table_size` 和 `max_heap_table_size`。
這些參數的預設值為 16 MiB。針對記憶體內暫存資料表使用 MEMORY 儲存引擎時，大小上限由 `tmp_table_size` 或 `max_heap_table_size` 值定義，以較小值為準。當達到此大小上限時，MySQL 會自動將記憶體內的內部暫存資料表轉換為 InnoDB 磁碟上內部暫存資料表。如需詳細資訊，請參閱[在 Amazon RDS for MySQL 和 Amazon Aurora MySQL 上使用 TempTable 儲存引擎](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)。
**注意**
使用 CREATE TABLE 明確建立 MEMORY 資料表時，只有 `max_heap_table_size` 變數會決定資料表的大小。也沒有轉換為磁碟上的格式。
## 相關指標
下列績效詳情指標與此洞察相關：
+ Created\$1tmp\$1disk\$1tables
+ Created\$1tmp\$1tables
如需詳細資訊，請參閱 MySQL 文件中的 [RCreated\$1tmp\$1disk\$1tables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html#statvar_Created_tmp_disk_tables)。