开发者学堂课程【MySQL 实战进阶：MySQL 分支-AliSQLSQL 的性能优化实战】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/83/detail/1311
MySQL 分支-AliSQLSQL 的性能优化实战
3、高效查询缓存
研发了高效的查询缓存，MySQL 本身也有这个查询缓存。为什么说重新研发了，在8.0基础上做的，MySQL 把8.0查询缓存去掉了。
左边的图没有缓存的时候，一个 SQL 语句进来要经过解析、检查权限、优化器对 SQL 进行分析，得出最好的执行计划，进行执行。执行过程中，可能涉及事务引擎，还可能访问存在磁盘上的数据，链路是非常长的。经过查询缓存命中的时候，这个过程变得非常简单。查询缓存是对结果集的缓存，所以称之为 consistent result cache，跟事务机制结合在一起，从缓存查出来的数据满足事物的隔离级别。在 4C8G 的测试，有100%的提升。测试了三个配置，第一个是查询缓存关闭的情况下，关闭的时候跟最高的比一倍不止。中间橙色的是 MySQL 原来的 cache，原来的 cache 涉及到成就在新的硬件上，起到了相反的作用，这也是8.0把它去掉的原因。但是解决其中最关键的问题涉及一个独到性的机制，缓存的更新维护机制，能够达到100%的性能提升。现在查询缓存可以自己开启，开启的参数都可以在控制台上修改，直接启用。
4、多块读
通过非常深入的代码阅读和分析，发现 MySQL 在处理 ra 的时候，是一个块一个块串行的去读。比如说要查询一张大表或 Automatic 的一张大表，对这张表加索引的时候，一块读完了再读下一块，这个过程是非常浪费时间的。在读第一个块的时候，把后面连续的块也读进来，所以称为多块读。也做了一个测试
左边的图对一张十个 G 的表采用原来的机制，需要115秒；右边使用多块读的技术，在 AIO 异步关闭的情况下，可以从115秒提升到67秒，当它打开的时候，提升效果会更明显，从115秒提升到43秒。最大的查询 select*from 一张表，查询大量的数据时会非常有效，所有的 DDL 也有效。
七、内核-稳定性
在稳定性方面的改进，也分为四个点。
1、快速 DDL
在业务高的时候，DDL 为什么抖动很大？在 MySQL 的 buffer pool 里，数据块是很多表或索引的数据是混合存放在 buffer pool 里面。做 DDL 的时候，要把 buffer pool 整个扫描一遍，扫描的效率是非常低的。有很多操作可以引起 buffer pool 的扫描，所有的 DDL、所有的对表进行重组的命令都会有这个过程，这个过程非常慢。所以在 buffer pool 里加入一个新的导航机制，可以快速的定位到哪些 buffer pool 是操作对象的，扫描效率会大大提升。下图是一个测试场景
是24 GB的 Buffer Pool，Buffer pool 一次是四个，128张表，每张表是200万条数据，这个过程中做 export tables 操作，这个操作会把buffer pool 扫描一遍。如果没有快速 DDL 特征的时候，需要80.51秒；有 DDL 这个特性以后，只需要0.34秒，这个特性也是在 RDS 56/57/80 上全部默认开启，是一个非常流行的全网功能。
2、性能监控插件
数据库经常遇到一些问题需要分析，这个时候实时性能数据非常重要。一般来说会 MySQL show performers metrics 查看，但是 show performers metrics 执行成本非常高，很难保证每秒钟性能数据的输出，所以把性能数据的收集做在内核里。从内核角度可以直接读取内存位置，然后把数据写到文件中，这样可以做到每秒钟一个数据，不管负载怎样，都会非常准时。
这些数据有两种存储方式，第一种是存在文本文件里，采用三个文件，每个文件到100M切换，可以对过去的性能信息进行回溯。另外还提供了一个内存的表，表中查询的时长是可以定义的，可以直接访问这张表。上图右上角是用graefner 做的曲线，对 select、insert、update、delete 等查询语句用曲线画出来。在分析性的问题的时候，可以用同一份数据进行交流，这样会加快问题分析的速度。
3、BP 动态伸缩
对 buffer pool 进行调节的时候扩大没有问题，缩小会有很大问题。为什么要调buffer pool？MySQL 使用内存分为两块，一块是数据内存，数据为了加速访问放在buffer cache 里；还有一块是程序，每个会话都会用内存。当硬件数据多的时候，buffer pool 要调小一些；当硬件数据小的时候，buffer pool 调大一些。动态的 buffer pool 机制能够更好地利用到内存，所有我们需要解决 buffer pool 动态缩小的问题。下图是一个测试
绿色的线是原生的 MySQL，在做 buffer pool缩小的过程中，它的抖动非常厉害，有很多次可能会跌到底。对这个问题进入深入的分析，进入 pool，之后再测试的时候看蓝色的线，虽然也有抖动，但是这个抖动的幅度小很多，最坏的情况跌20%。这个测试是在最忙的时候做的，BP动态伸缩技术加上其他业务相对不太高的时间段做的完全没有影响。
4、页面淘汰优化
MySQL 在内存比较紧张的时候，可能有单页淘汰。当要读一个数据块进入，在内存找不到空的数据页的时候，要淘汰一个数据页，会逐个淘汰，效率非常低。做了一个机制改进，把淘汰单个页的概率降到最低，提升了淘汰页面的效率，没有单页淘汰，最少是采用16页的淘汰，这样性能得到提升。下图中有四条线，两种场景，
上面两条线是测试 stability，没有打开范围查询的情况。绿色的线是页面优化之后的线，比没有优化之前提升了20%。下面两条线是打开范围查询的情况下，会查询比较多的记录，QPS 低一点，提升幅度在15%到20%。数据库数据大于内存，是一种常态，这方面的优化是一个非常大的提升，可以用更低的资源配置得到一个更高的CPU，这非常节约成本的事情。
八、内核-安全性
1、安全性方面的改进有三点，有一个点不深入讲解，是对国密算法的支持。数据安全的风险很大，国家对加密算法有要求，有自己的标准，所以增加了对 SM4 算法的支持，在 TDE 功能里面，可以选择用 SM4 算法进行加密。
2、防删表保护
在阿里云里面有几届数据库被认为删除的事件。把删除表的权限收到某个用户的指定账号，通过管控平台才能进行删除数据，或者要求删除操作只有在本地链接上才能操作，通过不同的级别可以起到不同的安全效果。从保护内容上来说有两类，第一类是数据类，包括 Drop Table、Truncate Table、Drop Partition、Truncate Paritition、Exchange Partition、Drop Tablespace ，还有一些对存储过程试图变的保护，选用这个级别的时候，可以禁止删除视图的定义，禁止删除存储过程，禁止删除触发器，甚至可以禁止删除 binlog。丰富多彩的结合可以起到很好的防数据保护的作用，可以确保数据库的运行安全。
3、DDL 回收站
在数据库8.0里，有 recycle bin 保留的数据库名字，recycle bin 字面的意思是回收站。在 AliSQL 8.0里，开启回收站功能之后，删除的时候就不是直接把这些表删掉，而是先把这些表移到回收站中。回收站概念非常常见，WINDOWS桌面就有回收站，不用的文件可以迁移到回收站，后续还可以找回。
但是对回收站的权限做了特别的控制，需要特别的权限才能真正获取这个表，一般来说是没有权限的，需要更高的权限，通过这样一个两级的机制，可以有效的防止表被删掉。或是不想开启防删表策略，可以开启回收站，发生错误的删表的时候，可以从回收站快速的找回数据，这是讲的两个安全的功能。
