相关概念

page size

innodb的数据是按数据页读取的,不是按记录读取(innodb中数据页大小默认是16k,见https://dev.mysql.com/doc/refman/8.0/en/innodb-init-startup-configuration.html)

对应的参数为innodb_page_size
innodb_page_size只能在初始化MySQL实例之前配置,之后不能改变。如果未指定任何值，则使用默认页面大小初始化实例
详见https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_page_size
对于32KB和64KB页面大小，最大行长度约为16000字节。当innodb_page_size设置为32KB或64KB时，不支持ROW_FORMAT = COMPRESSED。对于innodb_page_size = 32KB，范围大小为2MB。对于innodb_page_size = 64KB，范围大小为4MB。使用32KB或64KB页面大小时，innodb_log_buffer_size应设置为至少16M（默认值）。

默认的16KB页面大小或更大适用于各种工作负载，特别是涉及表扫描和涉及批量更新的DML操作的查询。
对于涉及许多小写入的OLTP工作负载，较小的页面大小可能更有效，其中当单个页面包含许多行时，争用可能是一个问题。较小的页面也可能对SSD存储设备有效，后者通常使用小块大小。保持InnoDB页面大小接近存储设备块大小可以最大限度地减少重写到磁盘的未更改数据量。

Change Buffer

Change Buffer是一种特殊的数据结构，缓存二级索引的页面的改变,当这些页面不在缓冲池中时.
INSERT，UPDATE或DELETE操作（DML）导致这个Buffer更改。这些更改当这些页面通过其他读取操作加载到buffer pool时会合并

与聚簇索引不同，二级索引通常不是唯一的，并且插入二级索引的顺序相对随机。同样，删除和更新可能会影响不在索引树中相邻的二级索引页。当受影响的页面被其他操作读入缓冲池时，合并缓存的更改，避免了从磁盘读取二级索引页到缓冲池所需的大量随机访问I / O.

系统大部分空闲时或在慢速关闭期间运行的清除操作会定期将更新的索引页写入磁盘。与每个值立即写入磁盘相比，清除操作可以更有效地为一系列索引值写入磁盘块。

当有许多受影响的行和许多要更新的辅助索引时，Change Buffer合并可能需要几个小时。在此期间，磁盘I / O会增加，这会导致磁盘绑定查询显着减慢。提交事务后，甚至在服务器关闭并重新启动之后，更改缓冲区合并也可能继续发生

在内存中， Change Buffer占用 buffer pool的一部分。在磁盘上， Change Buffer是系统表空间的一部分，其中在关闭数据库服务器时缓冲索引更改。

更改缓冲区中缓存的数据类型由innodb_change_buffering变量控制。您还可以配置最大更改缓冲区大小(innodb_change_buffer_max_size)。

如果索引包含降序索引列或主键包含降序索引列，则辅助索引不支持Change Buffer。
常见问题

redo log

redo log是在崩溃恢复期间用于纠正由未完成事务写入的数据的基于磁盘的数据结构。在正常操作期间，redo log会对由SQL语句或低级API调用产生的更改表数据的请求进行编码。在初始化期间以及接受连接之前，自动重播在意外关闭之前未完成更新数据文件的修改。

默认情况下，redo log在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。MySQL以循环方式写入重做日志文件。redo log中的数据根据​​受影响的记录进行编码;这些数据统称为redo。
在redo log中的的数据传递由不断增加的LSN值表示。

要更改redo log文件的数量或大小，请执行以下步骤：
停止MySQL服务器并确保它关闭而没有错误。
编辑my.cnf以更改日志文件配置。
要更改日志文件大小，请配置innodb_log_file_size。
要增加日志文件的数量，请配置innodb_log_files_in_group。
再次启动MySQL服务器。
如果InnoDB检测到innodb_log_file_size与重做日志文件大小不同，它会写入日志checkpoint,关闭并删除旧的日志文件，以请求的大小创建新的日志文件，并打开新的日志文件。

Redo Log Flushing的Group Commit
与任何其他符合ACID标准的数据库引擎一样，InnoDB在提交事务之前刷新事务的redo log。
InnoDB使用Group Commit 功能将多个此类刷新请求组合在一起，以避免每次提交一次刷新。
通过组提交，InnoDB会对日志文件发出一次写入操作，以便为几乎同时提交的多个用户事务执行提交操作，从而显着提高吞吐量。

LSN
“log sequence number”的缩写。这个任意的，不断增加的值表示与redo log中记录的操作相对应的时间点。
（此时间点与事务边界无关;它可以落在一个或多个事务的中间。）它在崩溃恢复期间由InnoDB内部使用，用于管理缓冲池。
在MySQL 5.6.3之前，LSN是一个4字节的无符号整数。当redo log文件大小限制从4GB增加到512GB时，LSN成为MySQL 5.6.3中的8字节无符号整数，因为需要额外的字节来存储额外的大小信息。
在MySQL 5.6.3或更高版本上构建的使用LSN值的应用程序应使用64位而不是32位变量来存储和比较LSN值。

undo log

undo log是与单个读写事务关联的 undo log记录的集合。undo log记录包含有关如何撤消事务到聚簇索引记录的最新更改的信息。如果另一个事务需要将原始数据视为一致读取操作的一部分，则从撤消日志记录中检索未修改的数据。 undo log存在于undo log segments中，这些日志段包含在rollback segments中。rollback segments驻留在撤消表空间和全局临时表空间中。

驻留在全局临时表空间中的撤消日志用于修改用户定义的临时表中的数据的事务。这些撤消日志不会被重做日志记录，因为它们不是崩溃恢复所必需的。
它们仅用于服务器运行时的回滚。这种类型的撤消日志通过避免重做日志记录I / O来提高性能。
每个撤消表空间和全局临时表空间分别最多支持128个回滚段。innodb_rollback_segments变量定义了rollback segments的数量。

rollback segments支持的事务数取决于rollback segments中的撤消槽数和每个事务所需的撤消日志数。

rollback segments中的撤消槽数(innodb页面大小/16)根据InnoDB页面大小而不同

事务分配四个undo log，每个是以下每种操作类型：
对用户定义的表执行INSERT操作
对用户定义的表执行UPDATE和DELETE操作
对用户定义的临时表执行INSERT操作
对用户定义的临时表执行UPDATE和DELETE操作
根据需要分配undo log。例如，对常规表和临时表执行INSERT，UPDATE和DELETE操作的事务需要完全分配四个undo log。仅对常规表执行INSERT操作的事务需要单个undo log。

在常规表上执行操作的事务将从分配的撤消表空间rollback segments中分配undo log。对临时表执行操作的事务将从分配的全局临时表空间rollback segments中分配撤消日志。

分配给事务的undo log在其持续时间内仍与事务相关联。例如，为常规表上的INSERT操作分配给事务的undo log用于该事务执行的常规表上的所有INSERT操作。

鉴于上述因素，可以使用以下公式来估计InnoDB能够支持的并发读写事务的数量。
在达到InnoDB能够支持的并发读写事务数之前，事务可能会遇到并发事务限制错误。当分配给事务的rollback segments用完撤消槽时，会发生这种情况。在这种情况下，请尝试重新运行该事务。
当事务对临时表执行操作时，InnoDB能够支持的并发读写事务数受限于分配给全局临时表空间的rollback segments数，默认情况下为128。

如果每个事务执行INSERT或UPDATE或DELETE操作，则InnoDB能够支持的并发读写事务的数量为
(innodb_page_size / 16) * innodb_rollback_segments * number of undo tablespaces

如果每个事务执行INSERT和UPDATE或DELETE操作，则InnoDB能够支持的并发读写事务的数量为：
(innodb_page_size / 16 / 2) * innodb_rollback_segments * number of undo tablespaces

如果每个事务对临时表执行INSERT操作，则InnoDB能够支持的并发读写事务的数量为：
(innodb_page_size / 16) * innodb_rollback_segments

如果每个事务对临时表执行INSERT和UPDATE或DELETE操作，则InnoDB能够支持的并发读写事务的数量为：
(innodb_page_size / 16 / 2) * innodb_rollback_segments

undo表空间包含undo日志。
undo log 存在于undo log segments中，这些日志段包含在rollback segments 中。rollback segments传统上驻留在系统表空间中。从MySQL 5.6开始，rollback segments 可以驻留在撤消表空间中。在MySQL 5.6和MySQL 5.7中，撤消表空间的数量由innodb_undo_tablespaces配置选项控制。在MySQL 8.0中，初始化MySQL实例时会创建两个默认的撤消表空间，并且可以使用CREATE UNDO TABLESPACE语法创建其他撤消表空间。

binlog

binlog包含描述数据库更改的“事件”，例如表创建操作或对表数据的更改。
它还包含可能已进行更改的语句的事件（例如，不匹配任何行的DELETE），除非使用 row-based logging 。binlog还包含有关每个语句获取更新数据的时间长度的信息。二进制日志有两个重要目的：

对于复制，主复制服务器上的binlog提供要发送到从服务器的数据更改的记录。
主服务器将其binlog中包含的事件发送到其从服务器，这些服务器执行这些事件以对主服务器上的数据进行相同的更改。

某些数据恢复操作需要使用binlog。还原备份后，将重新执行备份后记录的binlog中的事件。这些事件使数据库从备份点更新。

binlog不用于不修改数据的SELECT或SHOW等语句。要记录所有语句（例如，标识问题查询），请使用general query log。

运行启用了binlog记录的服务器会使性能稍慢。但是，binlog使您能够设置复制和还原操作的好处通常会超过此次要性能下降。binlog可以抵御意外停止。仅记录或回读完整的事件或事务。