提高MySQL的IO性能需要知道的一些事情

Posted 2021-06-20 johopig

文章讲到的内容都围绕着数据存储介质层：程序buffer、文件系统cache、硬盘。这三层贯穿全文，知道这个对文章内容理解有很大的帮助！

• 1. 参数配置

• 2. binlog

• 2.1 写入机制

• 2.2 格式

• 3. redo log

• 写入机制

• 4. 二阶段提交

• 5. 组提交

• 5.1 组提交的意义

• 5.2 LSN

• 5.3 过程

• 5.4 优化

1. 参数配置

• sync_binlog

1. sync_binlog=0，当事务提交之后，mysql不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

2. sync_binlog=1(默认)， 表示每次提交事务都会执行fsync；

3. sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

• innodb_flush_log_at_trx_commit

1. 设置为0的时候，表示每次事务提交时都只是把redo log留在redo log buffer中;
2. 设置为1的时候，表示每次事务提交时都将redo log直接持久化到磁盘；
3. 设置为2的时候，表示每次事务提交时都只是把redo log写到page cache。

• binlog_group_commit_sync_delay

binlog组提交，表示延迟多少微秒后才调用fsync;

• binlog_group_commit_sync_no_delay_count

binlog组提交，表示累积多少次以后才调用fsync。

2. binlog

2.1 写入机制

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

binlog各层结构.png

每个线程有自己binlog cache，但是共用同一份binlog文件。

• 图中的write，指的就是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快。
• 图中的fsync，才是将数据持久化到磁盘的操作。一般情况下，我们认为fsync才占磁盘的IOPS。

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

1. sync_binlog=0的时候，表示每次提交事务都只write，不fsync；
2. sync_binlog=1的时候，表示每次提交事务都会执行fsync；
3. sync_binlog=N(N>1)的时候，表示每次提交事务都write，但累积N个事务后才fsync。

因此，在出现IO瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成0，比较常见的是将其设置为100~1000中的某个数值。

2.2 格式

statement

为了说明statement 和 row格式的区别，我们来看一下这条delete命令的执行效果图：

图4 delete执行warnings

可以看到，运行这条delete命令产生了一个warning，原因是当前binlog设置的是statement格式，并且语句中有limit，所以这个命令可能是unsafe的。

为什么这么说呢？这是因为delete 带limit，很可能会出现主备数据不一致的情况。比如上面这个例子：

1. 如果delete语句使用的是索引a，那么会根据索引a找到第一个满足条件的行，也就是说删除的是a=4这一行；
2. 但如果使用的是索引t_modified，那么删除的就是 t_modified='2018-11-09’也就是a=5这一行。

由于statement格式下，记录到binlog里的是语句原文，因此可能会出现这样一种情况：在主库执行这条SQL语句的时候，用的是索引a；而在备库执行这条SQL语句的时候，却使用了索引t_modified。因此，MySQL认为这样写是有风险的。

row

当binlog_format使用row格式的时候，binlog里面记录了真实删除行的主键id，这样binlog传到备库去的时候，就肯定会删除id=4的行，不会有主备删除不同行的问题。

mixed

MySQL就取了个折中方案，也就是有了mixed格式的binlog。mixed格式的意思是，MySQL自己会判断这条SQL语句是否可能引起主备不一致，如果有可能，就用row格式，否则就用statement格式。

3. redo log

写入机制

redo log所在不同介质层

这三种状态分别是：

1. 存在redo log buffer中，物理上是在MySQL进程内存中，就是图中的红色部分；
2. 写到磁盘(write)，但是没有持久化（fsync)，物理上是在文件系统的page cache里面，也就是图中的黄色部分；
3. 持久化到磁盘，对应的是hard disk，也就是图中的绿色部分。

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

为了控制redo log的写入策略，InnoDB提供了innodb_flush_log_at_trx_commit参数，它有三种可能取值：

1. 设置为0的时候，表示每次事务提交时都只是把redo log留在redo log buffer中;
2. 设置为1的时候，表示每次事务提交时都将redo log直接持久化到磁盘；
3. 设置为2的时候，表示每次事务提交时都只是把redo log写到page cache。

不同innodb_flush_log_at_trx_commit的写入流程

事务还未执行完就被持久化的场景：

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

2. 一种是，redo log buffer占用的空间即将达到 innodb_log_buffer_size一半的时候，后台线程会主动写盘。注意，由于这个事务并没有提交，所以这个写盘动作只是write，而没有调用fsync，也就是只留在了文件系统的page cache。

3. 另一种是，并行的事务提交的时候，顺带将这个事务的redo log buffer持久化到磁盘。 假设一个事务A执行到一半，已经写了一些redo log到buffer中，这时候有另外一个线程的事务B提交，如果innodb_flush_log_at_trx_commit设置的是1，那么按照这个参数的逻辑，事务B要把redo log buffer里的日志全部持久化到磁盘。 这时候，就会带上事务A在redo log buffer里的日志一起持久化到磁盘。

4. 二阶段提交

如果在图中时刻A的地方，也就是写入redo log 处于prepare阶段之后、写binlog之前，发生了崩溃（crash），由于此时binlog还没写，redo log也还没提交，所以崩溃恢复的时候，这个事务会回滚。这时候，binlog还没写，所以也不会传到备库。到这里，大家都可以理解。

大家出现问题的地方，主要集中在时刻B，也就是binlog写完，redo log还没commit前发生crash，那崩溃恢复的时候MySQL会怎么处理？

下面是崩溃恢复时的判断规则：

1. 如果redo log里面的事务是完整的，也就是已经有了commit标识，则直接提交；
2. 如果redo log里面的事务只有完整的prepare，则判断对应的事务binlog是否存在并完整：a. 如果是，则提交事务；b. 否则，回滚事务。

因此，二阶段提交时，默认redo log commit阶段只write cache，不主动调用fsync，而是交由操作系统调用。这是因为前面prepare和binlog的刷盘，可以保证commit无须主动刷盘也不影响逻辑。

5. 组提交

可以分为redo log和binlog两个组提交。

5.1 组提交的意义

首先我们知道一个事务完整提交前，是需要等待两次刷盘的，一次是redo log（prepare阶段），一次是binlog。假如没有组提交，那么假如TPS是每秒2万的话，每秒就要写4万次磁盘。但其实mysql对这其中做了一些优化，使IOPS大大提升。

5.2 LSN

log sequence number，日志逻辑序列号。LSN是单调递增的，用来对应redo log、binlog的一个个写入点。每次写入长度为length的redo log， LSN的值就会加上length。详细的后面再介绍

5.3 过程

假设有三个并发事务 （trx1、trx2、trx3）在prepare阶段，他们都写完redo log buffer，等待持久化到磁盘中。LSN分别对应为50,100,150，这时：

• trx1因为是第一个执行的事务，所以会被选为这组的leader
• 等trx1要开始写盘的时候，这组里已经有三个事务了，这时的LSN是150
• trx1去写盘的时候，带的LSN=150，因此等trx1返回时，所有LSN小于150的redo log，都已经被持久化到磁盘
• 这时候trx2和trx3就可以直接返回

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

我们可以把上面二阶段提交那张图细化成另外一幅：

具体步骤为：

• redo log buffer写完后，write file cache，这时候不马上调用fsync刷盘
• 等待binlog的write file cache
• 由于上面这一步等待，因此redo log组里面也许刚好很多人赶上了这趟车，可以统统一次性fsync到磁盘中
• 由于上一步的刷盘，binlog组里也有很多人刚好可以赶上，因此也是统统一次性fsync到磁盘中
• redo log commit阶段直接write file cache

5.4 优化

通常情况下上图第3步执行得会很快（redo log是顺序IO），所以binlog的write和fsync间的间隔时间短，导致能集合到一起持久化的binlog比较少，因此binlog的组提交的效果通常不如redo log的效果那么好。当然，我们可以通过调整binlog组提交参数来改变这种情况。

• binlog_group_commit_sync_delay 表示延迟多少微秒后才调用fsync
• binlog_group_commit_sync_no_delay_count 表示累积多少次以后才调用fsync