# InnoDB 历史记录列表长度显著增加
<a name="proactive-insights.history-list"></a>

从 *date* 开始，您的行更改历史记录列表显著增加，最大达到 *db-instance* 上的 *length*。这一增加会影响查询和数据库关闭性能。

**Topics**
+ [

## 支持的引擎版本
](#proactive-insights.history-list.context.supported)
+ [

## 上下文
](#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 的所有版本都支持这些见解信息。

## 上下文
<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\$1kill](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\$1SCHEMA metrics table](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)。