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

# synch/mutex/innodb/fil\$1mutex
<a name="ams-waits.trxsysmutex"></a>

由於大量交易而有高資料庫活動時，`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)

## 相關的引擎版本
<a name="ams-waits.trxsysmutex.context.supported"></a>

下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 2 版和 3 版

## Context
<a name="ams-waits.trxsysmutex.context"></a>

在內部，InnoDB 資料庫引擎會使用可重複讀取隔離層級搭配快照，來提供讀取一致性。這可為您提供在建立快照時資料庫的時間點檢視。

在 InnoDB 中，所有變更一到達就會套用到資料庫，無論是否已遞交它們。這種方法表示，若沒有多版本並行控制 (MVCC)，連線到資料庫的所有使用者都會看到所有的變更和最新的資料列。因此，InnoDB 需要一種方法來追蹤變更，以了解在必要時要復原什麼。

若要這樣做，InnoDB 會使用交易系統 (`trx_sys`) 來追蹤快照。交易系統會執行下列動作：
+ 追蹤復原日誌中每個資料列的交易 ID。
+ 使用名為 `ReadView` 的內部 InnoDB 結構，其有助於識別快照可以看到哪些交易 ID。

## 等待變多的可能原因
<a name="ams-waits.trxsysmutex.causes"></a>

以一致且受控方式處理 (建立、讀取、更新和刪除) 交易 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)。

## 動作
<a name="ams-waits.trxsysmutex.actions"></a>

根據等待事件的原因，我們會建議不同的動作。

**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.trxsysmutex.actions.identify)
+ [檢查其他等待事件](#ams-waits.trxsysmutex.actions.action1)

### 識別造成事件的工作階段和查詢
<a name="ams-waits.trxsysmutex.actions.identify"></a>

通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看導致最高負載的等待事件。了解您是否可以最佳化資料庫和應用程式，以減少這些事件。

**檢視 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/)。

### 檢查其他等待事件
<a name="ams-waits.trxsysmutex.actions.action1"></a>

檢查與 `synch/mutex/innodb/trx_sys_mutex` 等待事件相關聯的其他等待事件。執行此動作可提供工作負載本質的詳細資訊。大量的交易可能會減少輸送量，但工作負載也可能使此變得必要。

如需如何最佳化交易的詳細資訊，請參閱 MySQL 文件中的[最佳化 InnoDB 交易管理](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)。