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

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介:

本文简单介绍下最新的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中才能看到怎么实现的了。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
1月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
2月前
|
存储 网络协议 关系型数据库
MySQL8.4创建keyring给InnoDB表进行静态数据加密
MySQL8.4创建keyring给InnoDB表进行静态数据加密
81 1
|
1月前
|
存储 SQL 关系型数据库
京东面试:mysql深度分页 严重影响性能?根本原因是什么?如何优化?
京东面试:mysql深度分页 严重影响性能?根本原因是什么?如何优化?
京东面试:mysql深度分页 严重影响性能?根本原因是什么?如何优化?
|
2月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
52 0
|
4月前
|
SQL 关系型数据库 MySQL
MySQL底层概述—10.InnoDB锁机制
本文介绍了:锁概述、锁分类、全局锁实战、表级锁(偏读)实战、行级锁升级表级锁实战、间隙锁实战、临键锁实战、幻读演示和解决、行级锁(偏写)优化建议、乐观锁实战、行锁原理分析、死锁与解决方案
238 24
MySQL底层概述—10.InnoDB锁机制
|
3月前
|
缓存 关系型数据库 MySQL
ThinkPHP框架show columns引发mysql性能问题
ThinkPHP框架的show columns引发mysql性能问题,结尾有关闭方式。
97 13
|
4月前
|
存储 缓存 关系型数据库
MySQL底层概述—5.InnoDB参数优化
本文介绍了MySQL数据库中与内存、日志和IO线程相关的参数优化,旨在提升数据库性能。主要内容包括: 1. 内存相关参数优化:缓冲池内存大小配置、配置多个Buffer Pool实例、Chunk大小配置、InnoDB缓存性能评估、Page管理相关参数、Change Buffer相关参数优化。 2. 日志相关参数优化:日志缓冲区配置、日志文件参数优化。 3. IO线程相关参数优化: 查询缓存参数、脏页刷盘参数、LRU链表参数、脏页刷盘相关参数。
178 12
MySQL底层概述—5.InnoDB参数优化
|
3月前
|
关系型数据库 MySQL OLAP
无缝集成 MySQL,解锁秒级 OLAP 分析性能极限,完成任务可领取三合一数据线!
通过 AnalyticDB MySQL 版、DMS、DTS 和 RDS MySQL 版协同工作,解决大规模业务数据统计难题,参与活动完成任务即可领取三合一数据线(限量200个),还有机会抽取蓝牙音箱大奖!
|
4月前
|
存储 SQL 关系型数据库
MySQL底层概述—4.InnoDB数据文件
本文介绍了InnoDB表空间文件结构及其组成部分,包括表空间、段、区、页和行。表空间是最高逻辑层,包含多个段;段由若干个区组成,每个区包含64个连续的页,页用于存储多条行记录。文章还详细解析了Page结构,分为通用部分(文件头与文件尾)、数据记录部分和页目录部分。此外,文中探讨了行记录格式,包括四种行格式(Redundant、Compact、Dynamic和Compressed),重点介绍了Compact行记录格式及其溢出机制。最后,文章解释了不同行格式的特点及应用场景,帮助理解InnoDB存储引擎的工作原理。
MySQL底层概述—4.InnoDB数据文件
|
4月前
|
存储 缓存 关系型数据库
MySQL底层概述—3.InnoDB线程模型
InnoDB存储引擎采用多线程模型,包含多个后台线程以处理不同任务。主要线程包括:IO Thread负责读写数据页和日志;Purge Thread回收已提交事务的undo日志;Page Cleaner Thread刷新脏页并清理redo日志;Master Thread调度其他线程,定时刷新脏页、回收undo日志、写入redo日志和合并写缓冲。各线程协同工作,确保数据一致性和高效性能。
MySQL底层概述—3.InnoDB线程模型

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多
    下一篇
    oss创建bucket