先来看一下2020年已经上线并且使用非常广泛几个功能和技术：

• Dynamic Thread Pool，AliSQL团队通过技术创新和改进，于年初在云上默认打开了线程池，56/57/80三个版本都已支持，已有100000+用户的数十万实例运行在线程池下，也就是让线程池不再挑场景，可以轻松胜任高并发的混合请求场景，而不像其他分支（如Percona或MariaDB）的线程池那样要求都是短平快的查询。到目前为止，我们应当是唯一一家默认开启线程池功能的RDS供应商，可以让实例支持更高的连接数，可以承受更强的短连接能力，可以节约宝贵的CPU和内存资源，可以提升上千并发（真实应用中连接数上千很容易）下的性能，让RDS客户在用更少资源得到更高QPS&TPS，享受到实实在在的技术红利。

• Faster DDL，在遇到几次用户业务高峰对小表做DDL的性能抖动后，AliSQL团队深入分析了整个DDL过程，发现在DDL过程中Buffer Pool的管理方式不够优雅，就对其进行了改进，并在56/57/80三个版本上同步实现并发布上线，目前已有100000+用户的数十万实例开启了此功能，极大的缩短了业务高峰进行DDL所需的时间，有效地消除了稳定性风险，让阿里云RDS客户享受到了实实在在的好处。

再来看一下2020年上线但还未达到上述使用量的功能和技术:

• Fast Query Cache，在架构设计中Cache为王，看Oracle 21中增加了对持久化内存的支持，累计达到7层缓存设计，我们当然不能放过Query Cache。Query Cache具有对应用完全透明的优势，在仔细压测分析原生Query Cache功能后，发现性能不够理想后，设计出了版本化的Fast Query Cache技术，解决了原生Query Cache中的并发性限制，使得纯读性能最高可以提升100%+，并且在写场景中基本没有额外性能损耗。欢迎大家来使用Fast Query Cache，如今已经可以自行调整内存参数进行开启，如果你还在用原生的Query Cache，则可以升级到较新的版本，来享受AliSQL带来了Cache技术红利。

• Recycle Bin & Data Protect，在2020年业界发生了几次由删库删表引起的安全事故，我们深表痛惜和警觉，AliSQL团队设计了Recycle Bin和Data Protect功能，以主动应对类似风险。Recycle Bin会自动将删除的表先移到回收站，直到进一步清空回收站（可以额外控制权限）时才会真正删除表，在Purge之前都可以从回收站中还原数据；而Data Protect则可以严格限制可以执行删除操作的用户，从权限和目标两个维度进行控制，以帮助大家保障数据安全（需要自行开启）。

• Flashback Query，有时侯可能面临执行错误DML语句（比如Delete/Update没有准确的Where条件）的紧急场景，会要求我们快速将数据恢复到错误DML语句执行之前的数据状态，过去我们需要去下载、分析Binlog文件，再利用工具去生成反向操作的SQL语句进行恢复，步骤比较复杂。在具备Flashback Query技术后，可以直接穿越到过去的时间点（误操作之前的）执行SQL语句，将准确的数据找出来进行快速恢复。

• MultiBlock Read，针对用户反馈的大表DDL或大查询慢的问题，AliSQL团队仔细分析了Buffer IO的代码逻辑，并找到了其中的欠缺，每次只读一个块是非常低效的行为，对于连续的数据块访问（Range Scan或Full Table Scan）可以一次性读取多个块来提升IO效率，从而使得大表扫描的速度提以大幅度提升，也就是说大查询或DDL的时间有望缩短25-50%左右。

• Faster LRU Scan，有相当一部份客户的业务发展非常好，数据量激增，给系统带来压力，在分析和支持客户发展的过程中，AliSQL团队发现原生MySQL的Buffer Pool LRU淘汰机制有欠缺，在访问的数据量远大于内存规格时，会进入低效的Singe Page Flush淘汰机制，存在着逻辑上的欠缺。对此我们优化和设计了一种更好的淘态机制，使得同等情况下QPS & TPS可以提升10-20%，让客户在同等的资源下可以有更高的性能，为客户切切实实地节约成本。

我们是第一个提供RDS 80服务的云产商，给社区排查和反馈了不少问题和缺陷，其中有一些是比较严重的会导致Crash的，在这里就不一一细说了。回顾2020年，真是相当忙而快乐的一年，忙是我们在努力为客户创建价值（提供技术红利），快乐是我们的一些技术和功能在云上得到大量的使用，并且还有一些非常有意义的事情（空间压缩、安全审计等方面）在等着我们去做。这就是RDS AliSQL 2020年的技术总结！谢谢。