本文简单介绍下最新的Mysql8.0.13版本几个和性能相关的小改动
1. bug#84958
问题描述：
当聚主要集索引记录上有多个版本时，从聚集索引上读取记录时的时间复杂度是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
主要改动:
在之前的版本中，innodb open一个read view，会先prepare()，在锁保护下拷贝全局事务id，然后在调用complete(), 去再更新ReadView的up_limit_id
complete可能在全局事务锁内或者锁外部执行。这实际上是没有什么必要的，complete()函数可以彻底移除掉，对应的代码转移到ReadView::prepare的执行路径中
官方测试在arm64场景下有一定的性能提升
undo truncate
从commit log来看，官方应该有个更加全面完善的修复方案，但在下一个版本修复，在当前版本只是做了部分修复。
问题描述：
从ＭySQL５.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中才能看到怎么实现的了。
