为什么我的MySQL会“抖”一下()
不知道你有没有遇到过这样的场景,一条 SQL 语句,正常执行的时候特别快,但是有时也不知道怎么回事,它就会变得特别慢,并且这样的场景很难复现,它不只随机,而且持续时间还很短。
1)InnoDB 在处理更新语句的时候与磁盘有关的操作是什么?
- 写日志
- redo log(重做日志):也就是《孔乙己》里咸亨酒店掌柜用来记账的粉板
- 更新内存写完 redo log ,返回给客户端。
4)掌柜总要找时间把账本更新这个对应数据库里面的什么操作?
- 把内存里的数据写入磁盘的过程。这个过程叫flush
- 不是,因为孔乙己今天的赊账金额还只在粉板上,而账本里的记录是老的,还没把今天的赊账算进去。
- 脏页
- 内存和磁盘上的数据页的内容一致时,这个内存页叫做干净页。
文章图片
文章图片
9)平时执行很快的操作,其实是在干嘛?
- 写内存和日志
- 在刷脏页(flush)
11.1)我们还是继续用咸亨酒店掌柜的这个例子,想一想:掌柜在什么情况下会把粉板上的赊账记录改到账本上?
- 第一种场景是,粉板满了,记不下了
- 这个场景,对应的就是 InnoDB 的 redo log 写满了.
- 这个场景,对应的就是 InnoDB 的 redo log 写满了.
- 第二种场景是,这一天生意太好,要记住的事情太多,掌柜发现自己快记不住了,赶紧找出账本把孔乙己这笔账先加进去。
- 这种场景,对应的就是系统内存不足。当需要新的内存页,而内存不够用的时候,就要淘汰一些数据页,空出内存给别的数据页使用。如果淘汰的是“脏页”,就要先将脏页写到磁盘。
- 这种场景,对应的就是系统内存不足。当需要新的内存页,而内存不够用的时候,就要淘汰一些数据页,空出内存给别的数据页使用。如果淘汰的是“脏页”,就要先将脏页写到磁盘。
- 第三种场景是,生意不忙的时候,或者打烊之后。这时候柜台没事,掌柜闲着也是闲着,不如更新账本。
- 这种场景,对应的就是 MySQL 认为系统“空闲”的时候。当然,MySQL“这家酒店”的生意好起来可是会很快就能把粉板记满的,所以“掌柜”要合理地安排时间,即使是“生意好”的时候,也要见缝插针地找时间,只要有机会就刷一点“脏页”。
- 这种场景,对应的就是 MySQL 认为系统“空闲”的时候。当然,MySQL“这家酒店”的生意好起来可是会很快就能把粉板记满的,所以“掌柜”要合理地安排时间,即使是“生意好”的时候,也要见缝插针地找时间,只要有机会就刷一点“脏页”。
- 第四种场景是,年底了咸亨酒店要关门几天,需要把账结清一下。这时候掌柜要把所有账都记到账本上,这样过完年重新开张的时候,就能就着账本明确账目情况了。
- 这种场景,对应的就是 MySQL 正常关闭的情况。这时候,MySQL 会把内存的脏页都 flush 到磁盘上,这样下次 MySQL 启动的时候,就可以直接从磁盘上读数据,启动速度会很快。
- 这种场景,对应的就是 MySQL 正常关闭的情况。这时候,MySQL 会把内存的脏页都 flush 到磁盘上,这样下次 MySQL 启动的时候,就可以直接从磁盘上读数据,启动速度会很快。
- 第三种第四种场景我们不需要关注性能,我们主要来看第一种和第二种。
- 第一种是“redo log 写满了,要 flush 脏页”,这种情况是 InnoDB 要尽量避免的。因为出现这种情况的时候,整个系统就不能再接受更新了,所有的更新都必须堵住。如果你从监控上看,这时候更新数会跌为 0。
- 第二种是“内存不够用了,要先将脏页写到磁盘”,这种情况其实是常态
- 缓冲池(buffer pool)
- 第一种是,还没有使用的;
- 第二种是,使用了并且是干净页;
- 第三种是,使用了并且是脏页。
15)当要读入的数据页没有在内存的时候,这时候该怎么办?
- 到缓冲池中申请一个数据页
- 这时候只能把最久不使用的数据页从内存中淘汰掉:如果要淘汰的是一个干净页,就直接释放出来复用;但如果是脏页呢,就必须将脏页先刷到磁盘,变成干净页后才能复用。
- 一个查询要淘汰的脏页个数太多,会导致查询的响应时间明显变长;
- 日志写满,更新全部堵住,写性能跌为 0,这种情况对敏感业务来说,是不能接受的。
- 控制脏页比例
- 首先,你要正确地告诉 InnoDB 所在主机的 IO 能力,这样 InnoDB 才能知道需要全力刷脏页的时候,可以刷多快。
- 这就要用到 innodb_io_capacity 这个参数了,它会告诉 InnoDB 你的磁盘能力。这个值我建议你设置成磁盘的 IOPS。磁盘的 IOPS 可以通过 fio 这个工具来测试,下面的语句是我用来测试磁盘随机读写的命令:
fio -filename=$filename -direct=1 -iodepth 1 -thread -rw=randrw -ioengine=psync -bs=16k -size=500M -numjobs=10 -runtime=10 -group_reporting -name=mytest
- 之前,就曾有其他公司的开发负责人说 MySQL 的写入速度很慢,TPS 很低,但是数据库主机的 IO 压力并不大。经过一番排查,发现罪魁祸首就是这个参数的设置出了问题。
- 他的主机磁盘用的是 SSD,但是 innodb_io_capacity 的值设置的是 300。于是,InnoDB 认为这个系统的能力就这么差,所以刷脏页刷得特别慢,甚至比脏页生成的速度还慢,这样就造成了脏页累积,影响了查询和更新性能。
- 200,所以如果主机磁盘用的是SSD,大家建议改为20000.
- 这个问题可以这么想,如果刷太慢,会出现什么情况?首先是内存脏页太多,其次是 redo log 写满。
- 所以,InnoDB 的刷盘速度就是要参考这两个因素:一个是脏页比例,一个是 redo log 写盘速度。
- innodb_max_dirty_pages_pct,默认值是 75%。
- InnoDB 会根据当前的脏页比例(假设为 M),算出一个范围在 0 到 100 之间的数字F1(M)
- InnoDB 每次写入的日志都有一个序号,当前写入的序号跟 checkpoint 对应的序号之间的差值,我们假设为 N。InnoDB 会根据这个 N 算出一个范围在 0 到 100 之间的数字,这个计算公式可以记为 F2(N)。
- 根据上述算得的 F1(M) 和 F2(N) 两个值,取其中较大的值记为 R,之后引擎就可以按照 innodb_io_capacity 定义的能力乘以 R%
文章图片
- 你的查询语句在需要内存的时候可能要求淘汰一个脏页。
- 刷脏页的逻辑会占用 IO 资源并可能影响到了你的更新语句。
- 合理地设置 innodb_io_capacity 的值,并且平时要多关注脏页比例,不要让它经常接近 75%。
- Innodb_buffer_pool_pages_dirty/Innodb_buffer_pool_pages_total
mysql> select VARIABLE_VALUE into @a from global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_dirty'; select VARIABLE_VALUE into @b from global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_total'; select @a/@b;
- 一起刷掉,如果邻居的邻居也是,也一起刷掉。这个就特别影响性能了。
- InnoDB 中,innodb_flush_neighbors 参数就是用来控制这个行为的,值为 1 的时候会有上述的“连坐”机制,值为 0 时表示不找邻居,自己刷自己的。
- 把 innodb_flush_neighbors 的值设置成 0,因为这时候 IOPS 往往不是瓶颈,而“只刷自己”,就能更快地执行完必要的刷脏页操作,减少 SQL 语句响应时间。
- 在 MySQL 8.0 中,innodb_flush_neighbors 参数的默认值已经是 0 了。
- 【为什么我的MySQL会“抖”一下()】redo log是关系型数据库的核心啊,保证了ACID里的D。所以redo log是牵一发而动全身的操作 ,当内存数据页跟磁盘数据页不一致的时候,把内存页称为'脏页'。如果redo log 设置得太小,redo log写满.那么会涉及到哪些操作呢,我认为是以下几点: 1.把相对应的数据页中的脏页持久化到磁盘,checkpoint往前推 2.由于redo log还记录了undo的变化,undo log buffer也要持久化进undo log 3.当innodb_flush_log_at_trx_commit设置为非1,还要把内存里的redo log持久化到磁盘上 4.redo log还记录了change buffer的改变,那么还要把change buffer purge到idb 以及merge change buffer.merge生成的数据页也是脏页,也要持久化到磁盘 上述4种操作,都是占用系统I/O,影响DML,如果操作频繁,会导致'抖'得向现在我们过冬一样。 但是对于select操作来说,查询时间相对会更快。因为系统脏页变少了,不用去淘汰脏页,直接复用 干净页即可。还有就是对于宕机恢复,速度也更快,因为checkpoint很接近LSN,恢复的数据页相对较少 所以要控制刷脏的频率,频率快了,影响DML I/O,频率慢了,会导致读操作耗时长。
推荐阅读
- 为什么 Nacos 会在单个集群中同时运行 CP 协议以及 AP 协议呢()
- 终篇-------MySQL主从
- MySQL优化之索引解析
- Koa2+mysql|Koa2+mysql 搭建用户信息注册和登录接口服务
- HTML|马上跨年了,室友靠我的十款不同表白代码顺利脱单【内附源码】
- 同事提出个我从未想过的问题,为什么Kubernetes要"多此一举"推出静态Pod概念()
- 前端|我的第一次移动端页面制作 — 总结与思考
- 为什么你问问题,别人都已读不回()
- Mysql系统学习|为什么不让用join(《死磕MySQL系列 十六》)
- 数据库|MySql笔记个人小记