MySQL8.0.13: 几个和innodb性能相关的小改动-阿里云开发者社区

开发者社区> zhaiwx_yinfeng> 正文

MySQL8.0.13: 几个和innodb性能相关的小改动

简介:
+关注继续查看

本文简单介绍下最新的Mysql8.0.13版本几个和性能相关的小改动

1. bug#84958

commit

问题描述:
当聚主要集索引记录上有多个版本时,从聚集索引上读取记录时的时间复杂度是0(N),但通过二级索引查询的时间复杂度可能为O(N^2)

解决思路:
代码是由facebook的工程师提供的补丁,主要思路是增加一个新的类Row_sel_get_clust_rec_for_mysql,其中cache了上次的clust record和老版本,可以在下次循环中重用。当发现定位到的clust rec和上次相同时,就无需遍历版本链,直接拿上次看到的版本,否则的话更新cach的记录

举个简单的例子,记录(1,2,3), pk = 1, sec index entry = (2,3);
记录更新为(1,2,4), 则sec index entry上记录为(2,3)(delete marked), (2,4), 均指向pk 1,那么在查询时可能需要去看对应的clust record.实际上看到的只有一个版本,那么在第二次找到(2,4),想去检查
记录可见性时,就可以直接使用上次拿到的版本,无需扫描版本链。

但这个实现也只是缓存上次的clust记录,这意味着如果在二级索引上扫描到的记录不是连续的,就可能用不上这个优化。

bug#91759

commit

主要改动:

在之前的版本中,innodb open一个read view,会先prepare(),在锁保护下拷贝全局事务id,然后在调用complete(), 去再更新ReadView的up_limit_id

complete可能在全局事务锁内或者锁外部执行。这实际上是没有什么必要的,complete()函数可以彻底移除掉,对应的代码转移到ReadView::prepare的执行路径中

官方测试在arm64场景下有一定的性能提升

undo truncate

commit

从commit log来看,官方应该有个更加全面完善的修复方案,但在下一个版本修复,在当前版本只是做了部分修复。

问题描述:
从MySQL5.7开始对独立的undo tablespace进行truncate操作,解决了之前被人诟病很久的undo膨胀问题,但在每次truncate undo tablespace时,执行真正文件操作之前和之后都需要做一次强制checkpoint。我们知道checkpoint在高负载场景下,带来的是极端page flush,高写入负载下,可能持续的影响到实例前端的吞吐量和相应时间。

那么为什么需要checkpoint呢? 个人理解是:

  • 当文件size缩小时,如果内存里还有脏页,可能在io时候无法写入抛错
  • 崩溃恢复时,无需去对已经truncate的page做日志应用

解决方案:

  • 在truncate文件之前,将对应undo tablespace的page从buffer pool驱逐掉
  • 在truncate文件之后,将涉及的dirty page flush到磁盘

既然不做checkpoint了,那么在崩溃恢复时,是否可能尝试去读取不存在的page做log application, 从而导致崩溃恢复失败呢? 个人觉得这里可能是存在bug的, 因为在崩溃恢复时并没有去检查page no是否在tablespace范围内,可能在fil_io时报invalid page accessing错误。已经report到官方,并被确认 bug#93170

SELECT COUNT(*)

目前社区已经有很多用户报select count(*)效率底下,其根本原因是从8.0开始,mysql默认使用clust index来计算总行数,其初衷是clust index上包含全部数据,没有二级索引的回表检查开销,而且只需要统计pk的个数即可。但这个优化方案忽略了二级索引可能比聚集索引更快:

  • 二级索引比聚集索引更小,因此产生的IO可能更小
  • 二级索引上记录并不总是需要回表

虽然8.0.13的release note写了select count() 被优化,但实际上这是个乌龙(只能说是回退吧...)。根据在slack上和innodb老大sunny的交流,真正的优化没有来得及合并进去,在release前三天被冻结住了。8.0.13只是实现了WL#10398,可以使用不同的索引来执行select count()。最终的官方的优化大体思路是通过在innodb并行scan btree来加速count(*),但恐怕我们只能在8.0.14中才能看到怎么实现的了。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PHP7+Swoole、Node Express、Sails、Beego、ThinkPHP 并发性能测试
最近由于产品业务出现请求瓶颈,需要更换产品框架,针对现在集中主流方案进行了逐一测试   服务器硬件配置:2 核 2G虚拟机 , 10000请求 500并发测试结果如下 性能测试结果 1、Nodejs Express测试结果如下 大约每秒处理2100请求 响应时间在230ms左右,cpu负...
2269 0
文章详情 PayPal 为什么从 Java 迁移到 Node.js:性能提高一倍,文件代码减少44%
大家都知道 PayPal 是另一家迁移到 Node.js 平台的大型公司,Jeff Harrell 的这篇博文 Node.js at PayPal 解释了为什么从Java迁移出来的原因:开发效率提高一倍(2个人用更少的时间干了5个人的活),性能提高一倍,代码量减少33%, 文件减少40%。
7 0
高性能以太坊节点服务QuikNode详细介绍
随着Web3的演化,开发者已经开始在以太坊区块链上快速开发去中心化应用。虽然在以太坊上开发dApp很酷,但是要搭建自己的以太坊节点还是挺令人头疼的一件事,这需要不短的时间,而且还需要一些技巧。QuikNode通过提供高性能的以太坊节点服务解决了这一问题,正如其官网所说,这是*运行专用以太坊节点的最快、最简单的方法*。
1694 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4439 0
阿里云 Node.js 性能平台(公测/商业化)发布
产品介绍: ["Node.js 性能平台(Node.js Performace Platform),是由阿里云所提供的,面向中大型 Node.js 应用提供 性能监控、安全提醒、故障排查、性能优化 等服务的整体性解决方案。
1125 0
+关注
zhaiwx_yinfeng
MySQL内核开发者, 《高性能MySQL 第三版》译者之一,活跃于MySQL社区,BugList,etc...
224
文章
5
问答
来源圈子
更多
阿里云数据库:帮用户承担一切数据库风险,给您何止是安心!支持关系型数据库:MySQL、SQL Server、PostgreSQL、PPAS(完美兼容Oracle)、自研PB级数据存储的分布式数据库Petadata、自研金融级云数据库OceanBase支持NoSQL数据库:MongoDB、Redis、Memcache更有褚霸、丁奇、德哥、彭立勋、玄惭、叶翔等顶尖数据库专家服务。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载