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

# InnoDB 歷史記錄清單長度顯著增加
<a name="proactive-insights.history-list"></a>

從{{日期}}到 {{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)

## 支援的引擎版本
<a name="proactive-insights.history-list.context.supported"></a>

所有版本的 Aurora MySQL 都支援此洞察資訊。

## Context
<a name="proactive-insights.history-list.context"></a>

InnoDB 交易系統會維護多版本並行控制 (MVCC)。修改資料列時，修改前的版本會在還原日誌中儲存為還原記錄。每個還原記錄都有對先前重做記錄的參照，進而形成一份連結清單。

InnoDB 歷史記錄清單是已提交交易的還原記錄全域清單。交易不再需要歷史記錄時，MySQL 會用歷史記錄清單來清除記錄和日誌頁面。歷史記錄清單長度是清單中所有修改項目的還原記錄總數。每個日誌都包含一個或多個修改項目。若 InnoDB 歷史記錄清單長度太長，表示該清單具有過多舊資料列版本，導致查詢和資料庫關閉變慢。

## 造成此問題的可能原因
<a name="proactive-insights.history-list.causes"></a>

歷史記錄清單過長的典型原因包括：
+ 長時間執行的交易 (讀取或寫入)
+ 繁重的寫入負載

## 動作
<a name="proactive-insights.history-list.actions"></a>

根據洞察的原因，我們會建議不同的動作。

**Topics**
+ [在 InnoDB 歷史記錄清單減少之前，請不要開始任何涉及資料庫關閉的操作](#proactive-insights.history-list.actions.no-shutdown)
+ [找出並關閉長時間執行的交易](#proactive-insights.history-list.actions.long-txn)
+ [使用績效詳情，找出最高主機和最高使用者。](#proactive-insights.history-list.actions.top-PI)

### 在 InnoDB 歷史記錄清單減少之前，請不要開始任何涉及資料庫關閉的操作
<a name="proactive-insights.history-list.actions.no-shutdown"></a>

InnoDB 歷史記錄清單過長會降低資料庫關閉速度，因此請在啟動涉及資料庫關閉的操作之前減少清單大小。這些操作包括主要版本資料庫升級。

### 找出並關閉長時間執行的交易
<a name="proactive-insights.history-list.actions.long-txn"></a>

您可以透過查詢 `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\_kill](mysql-stored-proc-ending.md#mysql_rds_kill) 結束每個長時間執行的交易。

### 使用績效詳情，找出最高主機和最高使用者。
<a name="proactive-insights.history-list.actions.top-PI"></a>

最佳化交易，以立即遞交大量已修改的資料列。

## 相關指標
<a name="proactive-insights.history-list.metrics"></a>

下列指標與此洞察相關：
+ `trx_rseg_history_len` – 您可以在績效詳情和 `INFORMATION_SCHEMA.INNODB_METRICS` 資料表中檢視此計數器指標。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB INFORMATION\_SCHEMA 指標資料表](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)。