MySQL的WAL（Write-Ahead Logging）机制

MySQL 里经常说到的 WAL技术，也就是先写日志，再写磁盘。

当内存数据页跟磁盘数据页内容不一致的时候，我们成这个内存页为“脏页”。内存数据写入磁盘后，内存和磁盘上的数据页内容就一致了，称为“干净页”。

MySQL 从 内存更新到磁盘的过程，称为刷脏页的过程（flush）。

InnoDB 刷脏页的时机：

往前推进之后，就要把两个点之间的日志对应的所有脏页都 flush 到磁盘上。

这种情况是 InnoDB 要尽量避免的。因为出现这种情况，整个系统都不能接受更新。更新数会跌为0。

那么为什么不能直接淘汰所有的内存，下次请求的时候，再从磁盘读入数据页，然后 拿 redo log 出来应用？这其实也是从性能的角度来考虑的，刷脏页一定写盘，就保证了每个数据页只有两种情况：

这种情况在日常应用中其实是常态。 在InnoDB 中，使用缓冲池 （buffer pool）管理内存，缓冲池中的内存页有三种状态：

刷脏页是常态，所以如果出现以下的情况，都会明明显影响性能：

首先，需要让 InnoDB 正确指导系统的 IO 能力，来控制刷脏页的快慢。

innodb_io_capacity 这个参数，它会告诉 InnoDB 你的磁盘能力，所以尽量设置成磁盘的 IOPS。可以使用 fio 工具来获取。

然后，如果你来设计策略控制刷脏页的速度，会参考哪些因素呢？

这个问题可以这么想，如果刷太慢，会出现什么情况？首先是内存脏页太多，其次是 redo log 写满。

所以，InnoDB 的刷盘速度就是要参考这两个因素：一个是脏页比例，一个是 redo log 写盘速度。

参数 innodb_max_dirty_pages_pct 是脏页比例上限，默认是 75%。InnoDB 会根据当前的脏页比例，计算出一个数字 F1。

InnoDB 写入日志都会有一个序号，当前写入序号跟 checkpoint 对应的序号之间的差值，假设为N。InnoDB 会根据N 计算出 F2.

根据 F1和F2 取其中较大的值为 R，之后引擎就可以按照 Innodb_io_capacity 定义的能力乘以 R% 来控制刷脏页的速度。

MySQL 中有一个机制，刷脏页的时候如果数据页旁边的数据页也是脏页，那么就会一起刷掉，而且这个逻辑是可以蔓延的，所以对于每个相邻的数据页，都会被一起刷。

在 InnoDB 中，innodb_flush_neighbors 参数就是用来控制这个行为的，值为 1 的时候会有上述的“连坐”机制，值为 0 时表示不找邻居，自己刷自己的。

在使用机械硬盘时，这个优化很有意义，可以减少很多随机 IO。如果使用的是 SSD 这种IOPS 比较高的设备，可以设置innodb_flush_neighbors 为0，只刷自己，这个时候 IOPS 往往就不是性能瓶颈了。只刷自己就可以提高刷脏页的速度，减少 SQL 语句的响应时间。

binlog 的写入机制比较简单：事务执行的过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到binlog 文件中。

系统给 binlog cache 分配了一片内存，每个线程一个，参数 binglog_cache_size 用于控制单个线程内 binlog cache 的内存大小，超过就要暂存在磁盘。

事务提交的时候，执行器把 binlog cache 里完整事务写入到 binlog 中，并清空 binlog cache。

write 和 fsync 的时机，是由参数 sync_binlog 控制的：

因此，在出现 IO 瓶颈的场景里，将 sync_binlog 设置成一个比较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成 0，比较常见的是将其设置为 100~1000 中的某个数值。但是，将 sync_binlog 设置为 N，对应的风险是：如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志。

事务的执行过程中，生成的 redo log 是要先写到 redo log buffer 的。

redo log 三种状态：

日志写到 redo log buffer 是很快的，write 到 page cache 也差不多，但是持久化到磁盘的速度就慢多了。

InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，取值如下：

InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。

组提交 机制

日志逻辑序列号（log sequence number，LSN）是一个单调递增的值，对应 redo log 的一个个写入点。每次写入的长度为 lenght 的 redo log，LSN的值就会加上 length。

LSN 也会写到 InnoDB 的数据页中，来确保数据也不会被多次执行重复的 redo log。

在一组提交里面，组员越多，节约磁盘 IOPS 的效果越好。在并发更新的场景下，第一个事务写完 redo log buffer 以后，接下来这个 fsync 越晚调用，组员可能越多，节约 IOPS 的效果就越好。

WAL机制主要得益于两个方面：

如果你的 MySQL 现在出现了性能瓶颈，而且瓶颈在 IO 上，可以通过哪些方法来提升性能呢？

针对这个问题，可以考虑以下三种方法：

InnoDB在处理更新语句时，先写内存再写redo log，并不会立即将数据页的更新落地到磁盘（WAL机制），这就会产生升内存数据页和磁盘数据页的数据不一致的情况，这种数据不一致的数据页称为 脏页 ，当脏页写入到磁盘（这个 *** 作称为flush）后，数据一致后称为干净页。

第3种是系统空闲不会有性能问题，第4种是要关闭了不考虑性能问题。第1和2的情况flush脏页会产生系统性能问题。

此时整个系统不能再更新了，更新数会降为0，所以这种情况要尽量避免。

InnoDB缓冲池（buffer pool）中的内存页有三种状态：

当一个SQL语句要淘汰的脏页数量太多，会导致语句执行的响应时间显著边长。

InnoDB为了避免出现上述两种情况，需要有控制脏页比例的策略，控制的主要参考因素就是：脏页比例和redo log写盘速度。

需要告诉InnoDB的磁盘读写能力（IOPS）让引擎全力flush脏页，磁盘的IOPS可以通过fio工具测试。

如果 innodb_io_capacity 参数设置的不合理，比如远远低于磁盘实际的IOPS，InnoDB会认为IO性能低，刷脏页速度会很慢，甚至低于脏页的生成速度，导致脏页累计影响查询和更新性能。

为了兼顾正常的业务请求，InnoDB引擎控制按照磁盘IOPS的百分比来刷脏页，具体流程如下：

脏页比例计算:

Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total

SQL语句如下：

在准备flush一个脏页时，如果相邻的数据页也是脏页，会把这个脏页一起flush，而且对这个新的脏页还可能有相邻的脏页导致连锁flush。

InnoDB使用 innodb_flush_neighbors 参数控制这个行为，值为1会产生上述连锁flush的情况，值为0则不会找相邻页。

找相邻页flush的机制虽然可以减少很多随机IO，但会增加一次flush时间，导致flush时的SQL语句执行时间变慢。

现在基本都使用的SSD这种IOPS比较高的硬盘，建议将 innodb_flush_neighbors 参数设为0，提高flush的速度。

flush会占用IO资源影响了正在执行的SQL语句，本来正常情况下执行很快的一条语句，突然耗时大大增加，造成业务抖动。要尽量避免这种情况，需要合理的设置 innodb_io_capacity 的值，并且多关注脏页比例，不要让脏页比例经常接近75%。

【极客时间】 MySQL实战45讲：第12节

字符串加索引的方式？

对于字符串进行添加索引，我们除了对整个字符串加索引以外，还可以添加前缀索引。

什么是前缀索引？

前缀索引的好处？

使用前缀索引，定义好长度，可以做到即节省空间，又不用额外增加太多的查询成本。

前缀索引的弊端？

前缀索引会使覆盖索引失效，额外增加回表的消耗，如果前缀索引的长度选择区分度不高，会额外导致扫描行数增加。

其他给字符串加索引的方式？

什么是脏页？

MySQL在更新数据的时候会写redo log并且更新内存以后就会返回，数据文件并不会立即更新，这就是所谓的WAL机制。

当内存被更新以后，内存中的数据页就会和磁盘上的数据页存在不一致的情况，该内存也就被称为 脏页 。

内存中的数据被写入磁盘以后，内容变为一致，此时该内存页就被称为干净页。

什么叫刷脏页？

内存数据页中的内容被写入磁盘数据页中的过程称为刷脏页。

什么时候会刷脏页？

InnoDB如何控制刷脏页的频率？

首先确认InnoDB所在主机的IO能力，此时需要用到数据库的innodb_io_capacity参数，该参数推荐设置为磁盘的IOPS。磁盘的IOPS可以通过fio工具进行测试。

InndoDB刷脏页主要考虑以下两个因素：

MySQL会根据F1(M)和F2(N)两个值，取其中较大的值记为R，之后引擎可以按照innodb_io_capacity定义的能力乘以R%来控制刷脏页的速度。

脏页比例

参数innodb_max_dirty_pages_pct是脏页比例的上限，MySQL 8.0中是90%。

当前脏页比例可以通过Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total计算获得，具体sql计算指令如下：

连坐机制

InnoDB在刷脏页的时候，如果该脏页旁边的是页也是脏页，会同时把相邻的脏页刷掉。

该刷脏页行为由参数innodb_flush_neighbors控制:

对于机械硬盘，开启连坐会减少随机IO的消耗，但对于SSD，没必要开启该参数。

---