内容简要：
一、关于内核
二、内核特性详解
一、 关于内核
（一）回归内核
基于阿里云对内核重要性的判断，我们投入大量精力进行内核研发。
在使用云的时候，可能存在决策时间、价格商谈时间、数据迁移时间和运行时间。当这些东西完成之后，我们发现一个稳定的数据库内核尤为重要，因为它伴随了用户最长的时间，因此我们花费大量的精力提升内核，并取得了不错的效果。
（二）内核研发
2020年初，阿里云对数据库内核研发进行构思，从两个方向着手，一是从用户/客户角度，第二个是从技术要求方面，下面分别作出介绍。
1.客户角度
客户角度
客户角度分为四个方面：实用性、高性能、稳定性、安全性。
首先，我们希望加一些非常实用的功能。例如Outline功能，可以临时修改一个SQL的执行计划，把它从错误的计划变成正确的执行计划。还有Flashback功能，当数据有误操作的时候，可以快速找回误操作之前的数据，这些功能具备十分强的实用性。
第二个是提高性能，我们希望有更高的QPS和更低的RT，这对应用十分重要。
第三个是稳定性，我们希望提升高并发场景下的稳定性和更快的问题分析能力。
第四个我们希望提升安全性，比如说我们对于通信与数据存储进行加密。我们实现防止随意删表，对删表流程做特殊权限控制。我们研发回收站，当用户有删除操作时，先将东西放到回收站而不是直接删除，同时对回收站设置特别的权限控制。
阿里云在考虑研发客户需求内容时，基本遵从以上四点进行。
2.技术要求
技术要求
技术要求分为四点：云场景、通用性、连续性、领先性。
首先，过去大家认识AliSQL可能是通过电商业务的秒杀场景开始，但我们认为不应受到电商业务场景的局限，而应该从云上用户场景出发，希望我们的技术能够让所有的云用户受益。
第二是功能和技术须具备通用性。通用性指功能的使用不受场景限制，适用于所有场景，用户无需修改SQL或应用。
第三点希望这些功能在不同的版本之间具有连续性，我们的技术在RDS 56/57/80上行为一致。
第四个是技术领先性，或者称为独创性。我们希望这些技术或功能具备其他版本都没有的创新，是一些独到性的需求。
（三）内核特性
按照客户角度分类，我们对上述四个技术又进行详细划分。
1.实用性
实用性方面实现四个功能，分别是是动态线程池技术，Flashback查询，SQL Outline和自动热点排队。
2.高性能
高性能方面实现了四个功能，分别是索引锁优化提升性能，Binlog In Redo，高效MySQL查询缓存和多块读技术。
3.稳定性
稳定性有四方面改进，分别是快速DDL，性能监控的插件，BP动态伸缩与页面淘汰优化。
4.安全性
在安全性方面，增加了对国密算法的支持，并实现防删表的功能和创立DDL回收站。
（四）版本对齐
上图为每个功能在各版本上的情况。我们研发首先是从8.0版本开始，之后是5.7版本，最后是在5.6版本，其中有两个功能不在5.6版本实现。
第一个是SQL Outline，因为这依赖于Hint技术， 5.6版本原生框架里不支持Hint技术。
第二个是BP动态升缩，5.6版本原生框架里同样没有提供该项支持这块。
除了上述两项功能，其他的功能三个版本均可对齐，表明我们目前实现的功能大多具备良好的延续性。
（五）全网功能
在上述功能中，有部分功能达到数十万实例开启，称为全网功能。
如上图所示，全网功能有四个，分别是动态线程池、索引锁优化、快速DDL和性能监控插件。全网功能的要求是数字化实例开启使用，运行一年且没有出现问题，我们接下里的目标是在2021年让2020所有功能都成为全网功能。
二、内核本质解析
（一）实用性
l 实用性主要从四个方面体现：
动态线程池；
Flashback查询；
SQL Outline；
自动热点排队；
1.动态线程池
动态线程池的重要性不言而喻，随着数据库的使用越来越深入，数据量也越来越大，应用到数据库连接数越来越高。
在一般情况下，性能会随着连接数变大而下降，上图灰线横坐标是数据库的连接数，纵坐标QPS。在达到一定并发以后，连接数开始下降，但在动态线程池的基础下，可以变成完整平滑的线。
我们认为线程池有四个非常重要的功能，首先是RDS 56/57/80独家默认开启，第二个是节约内存，第三个是节约CPU，第四个是节约线程资源，这些功能解决了许多问题。
首先是高并发的问题，当来了一个数量大且多的请求，例如秒杀场景，来了三千到一万的请求，线程池可以保证性能不下降。
第二个是解决了高连接问题，可以让RTS支持更高的连接数，通过线程池技术，连接数在技术上最高达到了50万。
第三个是高性能，如上图曲线所示，在上1000个连接以后，差距会越来越明显，到8000个链接时，原来的SQL几乎罢工，这种情况通过动态线程池得到解决。
线程池收益
上图为使用线程池之后的收益情况案例。左图和右图分别代表不开启线程池和开启线程池的区别。
当没有开启线程池时，可以看到Load数值很高，Process CPU的利用率与内存也存在不少区别。当没有开启线程池时，内存是10个GB，开启线程池后Load降到3.98，内存节约了200MB，这是一个非常显著的提升。
上图下方黑图是一个真实实例备库的性能数据，它的数据库连接数有15400个连接，在开启动态线程池后，后端只需要127个线程就可以提供非常平稳的服务。
2.Flashback查询
很多时候用户可能会遇到以下场景，如有些表不小心做一些误操作，例如Update语句的Where条件写错，或者根本就没有指定条件，或者Delete的语句，这些非常具有伤害性。
当遇到这些情况，原来的解决办法是解析Binlog进行数据恢复，现在我们在SQL语句里加了一个“as of timestamp”语法，使得我们可以回到过去的时间点，将误操作之前的数据查出来，然后用这些数据进行恢复。
3.SQL Outline
如上图所示，可以看到SQL计划很多时候可能会发生变化。
当用户做了SQL索引的增减索引，做了统计信息的重新收集，做出数据库版本的升级，调了一些参数，数据分布的变化，优化器的缺陷，程序固化等，这些情况都会造成SQL计划的改变，我们可以通过解决Outline这些情况。
上图右边是一个真实案例，这个SLQ交易顺序出错导致性能很差。通过Outline技术，只需要调用一个存储过程，给SQL设置一个Hint，执行计划准确运行，这种技术给业务、应用开发提供了一个有效的应急手段。
4.自动热点排队
自动热点排队是我们对AliSQL秒杀技术的一个升级。
秒杀技术是对同一行的更新，在事务上排队且不让它进入事务层，因为同一行的更新进入到事务引擎层时，会使得事务引擎实时检测成本非常高。这时候我们第一版本加了几个Hint，告诉SQL要用什么ID进行排序，这个ID通常指主键。
现在通过语法分析，可以把这一部分透明化的，不用去更改SQL，可以自动识别语句是走的是主键或者UK索引，如果是走的主键或者UK索引表示单行更新，那么可以自动把Where调节值取出来进行Hash，然后分配一个队列。
（二）高性能
l 高性能主要从四个方面体现：
1）索引锁优化；
2）Binlog In Redo；
3）高效查询缓存；
4）多块读；
1.索引锁优化
当数据库的数据间插入时，可能会导致索引的分裂，这个操作在MySQL里其实非常重要。我们在这块做了优化之后，大幅减少索引分裂的概率和深度。这里的深度是防止这种情况从叶子间里一直分到根，导致层层传递上去裂变恶化，这样带来好处是50%的TPCC性能的提升。
上图是一个测试，在实验室里我们可以把MySQL TPCC的值压缩到39万，左边是真实运行的截图，这表明压缩数据是真实的。右边是我们的检查测试，可以看到索引锁优化对检查也有帮助，可以要到100万Point Select。
2. Binlog In Redo
Binlog In Redo技术可以提升Commit的效率。
MySQL为了保证数据的一致性，它要求Redo Log和Binlog要同时刷出去也就是Redo Log和Binlog的两阶段提交机制。当一个事务开始之后，到提交阶段首先会Flush RedoLog，这个会设计成Release Lock。接下来会Flush Binary Log，也设计成Release Lock，然后才是真正的锁释放。我们在使用存储或者云盘时，可能会让性能会变得不那么理想。
我们研发的Binlog In Redo解决了这个问题，我们把Binlog先写在Redo里，只要刷一次Redo之后便可以保证后续的Binlog不会丢失，因此用户真正需要的Release Lock只有一次了。
如上方左边的流程图所示，用户在一次Release Lock之后，就可以把整个事务锁中的锁释放，提高了Commit的响应速度，也更早的释放了锁的资源。
这个带来了几个好处，一个是增强事务并发性，另一个是用户事务提交的性能得到提升。在我们的测试中，性能可以提升25%左右，适用于任何场景。
3.高效查询缓存
MySQL本身具备查询缓存功能，这里说我们重新研发的原因在于社区8.0把查询缓存剔除，我们觉得缓存其实是个非常好的东西，因此我们在8.0基础上重新研发。
如上图左边所示，如果没有缓存的时候，一条SQL语句进来要经过解析、检查权限、优化器对SQL进行分析，得出执行计划，然后真正的执行。执行过程中可能涉及事务引擎，还可能访问磁盘上的数据，所以说这个链路非常长。
我们这里的查询缓存是对结果起的一个缓存，所以我们称之为Consistent Result Cache。Consistent是跟事务机制结合在一起，意味着从缓存查出来的数据满足事务隔离级别。
我们在4C8G的机器上测试时，发现可以有100%的提升。我们测试了三个配置，第一个是将MySQL原生查询缓存关闭的情况下，在最高峰值的时候同比其他配置不足一半。
中间橙色是MySQL原来的Query Cache，这个是我们在5.7版本上做的。原来Query Cache因为设计比较陈旧，因此他在应急下其实起到反作用,这也是社区8.0将它去掉的原因，但是我们解决其中最关键的问题，设计了一个独到性的缓存维护与更新维护机制，达到100%的性能提升。目前查询网站已经可以自己开启了，这些开启的参数都在控制台进行修改，可以直接启用。
4.多块读
我们通过深入的代码阅读和分析，发现MySQL在处理RL的时候，基本上都是逐块读取。例如要查询一张大表，或者要去Optimize打表，或者对于这个表加一个索引时，会发现系统会逐块读取与处理，这个过程十分浪费时间。我们考虑到可以在读第一个块的时候，将后续的块也读进来，我们将这个称为多块读。
如上图所示，我们做了个测试。上图左边这是一个10G的表，采用原来的机制耗时115秒，右边为使用多块读技术，我们发现即使在AIO关闭的情况下，耗时仍会从115秒缩减到67秒。而当AIO打开的时候，由于本身对AIO有合并作用，提升效果更加明显，从115秒缩减到43秒。
（三）稳定性
l 稳定性方面实现了四个功能：
1）快速DDL；
2）性能监控插件；
3）BP动态伸缩；
4）页面淘汰优化；
1.快速DDL
以前有用户过来找到我们，表示在高业务环境下做的DDL抖动很大。我们发现在MySQL的Buffer Pool中，很多表或者索引的数据是混合存放在同一个Buffer里。当用户要做DDL的时候，可能要把整个Buffer Pool扫描一遍，扫描效率很低。基本上所有的DDL、对表、进行重组等操作都会有这个过程，过程十分缓慢。
因此，我们在Buffer Pool加入一个新的导航机制，用户可以快速定位到相应的操作对象，扫描效率得到大幅度提升。
上图是一个测试的场景，是一个24G的Buffer Pool，Instances是4个。我们开启了一个压测，128张表，每张表200万条数据，然后在过程中做Export Tables，这个操作会把Buffer Pool描仪一遍。当没有快速DDL特性时，过程耗时80.51秒，当有快速DDL后，过程耗时0.34秒，对比显著。
目前快速DDL在RDS 56/57/80默认开启，是一个非常流行的全网功能。
2. 性能监控插件
数据库中我们会经常遇到一些新的问题需要去分析，此时一个实时的性能数据就显得尤为重要。
一般情况我们会登到MySQL中用“show global status”来查看，但“show global status”执行成本高昂，很难保证每秒钟都有新的数据输出。因此，我们将性能数据的收集做到内核中，然后从内核的角度，可以直接读取内存位置，然将数据写到文件里，这样可以做到每秒钟一个数据，无论负载情况如何，基本上都非常准时。
这些数据有两种存储方式，第一个是存在格式化文本文件里面，我们采用三个文件，每个文件到100MB就切换，这样可以对过去的性能信息进行回溯。
另外我们提供了一个内存表，这个表的可查询时长是可自定义的，用户可以直接访问这些表。例如上图右上方的曲线，我们把对实例的Select、Insert、Update、Delete和Query语句，用曲线画出来这些数据。用户们都可以访问，当大家在分析新问题的时候，我们可以跟用户基于同一份数据来进行交流，加快问题分析的速度。
3.BP动态伸缩
我们发现，对Buffer Pool进行伸缩调节的时候，扩大没有问题，但缩小的时候会有很大问题。
我们为什么要调Buffer Pool？MySQL内存使用分成两块，一块是数据内存，一块是程序，每一个规划都会用到一些内存。当连接数据多的时候，其实Buffer Pool需要调小一点，当连接数比较少的时候，Buffer Pool可以调大一点，动态的Buffer Pool机制能够更好地利用内存，因此我们需要解决Buffer Pool动态伸缩的问题。
上图为一个测试，绿色线是原生的MySQL，我们在做Buffer Pool缩小的过程中，发现它抖动得非常厉害，很多时候甚至可能会跌到底，我们对这个问题进行深入分析，并进行技术突破。
蓝线是BP动态伸缩的技术下的反馈，虽然也有抖动，但抖动幅度大幅减少，最坏的情况跌20%。这个测试是在业务高峰时段进行，如果在业务不那么繁忙的阶段，我们有信心做到没有抖动。
4.页面淘汰优化
我们发现，当MySQL在内存紧张时容易引入单页淘汰，也就是当要读一个数据块时，如果在内存里找不到空的数据页，则会淘汰一个数据页。
此时是逐页淘汰，效率非常低下。在这里我们做了一个机制改进，将淘汰一个页的概率降到最低，提升了淘汰页面的效率，用同时淘汰多页代替逐页淘汰，性能得到大幅提升。
上图为一个测试，4条线是2种场景，上面两条线是测试，没有打开范围查询。
高的线是我们页面淘汰优化之后的线，相比优化前提升了20%。下面两条线是打开范围查询的情况。由于它有些SQL较为复杂，会查询比较多的记录，所以QPS会低一点，我们发现提升幅度也是差不多在15～20%。
数据库数据大于内存是一种常态，因此这里的优化是很大的提升，意味着可以用更低的资源配置得到更高的CPU，有效节约了成本。
（四）安全性
l 安全性实现了三个功能：
国密(SM4)支持；
防删表保护；
DDL回收站；
1.国密(SM4)支持
由于数据安全风险很大，国家对加密算法也有一定的要求与标准，因此我们增加了对国密SM4算法的支持，这点就不展开详细讲述了。
2.防删表保护
2020年的时候，业内发生数件数据库表被意外删除的事情，阿里云居安思危，未防止此类事情发生，我们设计了一个防删表的功能。
这个功能可以设置删除表的权限，例如需要收到某个用户的指定账号，或者要Super权限，或者需要通过内部管控平台操作，或者要求删除操作只能在本地登录进行，通过不同的权限设置可以起到不同的安全级别效果。
从保护内容方面可以分为两类，第一类是数据类的，包括Drop Table、Truncate Table、Drop Partition、Truncate Partition、Exchange Partition和Drop Tablespace。还有一类是对存储过程、视图以及定义的保护，当用他人想用这个级别的时候，用户可以禁止他人删除视图的定义、存储过程、触发器，甚至可以禁止删除Binary Log。
多样可选的设置相结合，可以起到很好的数据保护作用，确保用户的数据库安全运行。
3.DDL回收站
出于对DDL方面的考虑，我们做了个DDL回收站。
如上图左边所示，在AliSQL 8.0版本数据库中，我们有一个“recycle_bin”保留数据库名字，字面意思是回收站。
回收站这个概念大家非常常见，DDL回收站的概念与Windows回收站类似，但我们对回收站的权限做了特别的控制，需要有特别的权限才能进行彻底删除。
在AliSQL 8.0中，当开启回收站功能后，用户的删除操作不是直接将表删除，而是将这些表先移到回收站。
上图右边一般来说没有权限，它需要拥有更高的权限之后才可以进行删除操作。通过这样的两级机制，可以有效防止表被删掉。当用户不想开启防删表策略时，可以开启回收站，当用户发生误操作、误删表时，可以从回收站快速找回数据。
