这么快到2020年底了，看到Oracle 21c文档中的一些功能，想想AliSQL在2020年也做了不少事情，也有必要总结分享一下。为了让大家更好地知道有哪些特性，可以在哪些业务场景中使用到，也是为了2021年更好的向前发展。在年初时计划的一些企业级功能基本上都实现了，并且在过程中特别强调了功能的场景通用性，不再是从某个行业某个特定业务或应用场景设计（比如电商秒杀），而是从云上众多用户的不同场景出发，并且不需要用户应用或SQL改造配合（直接一个开关就可以开启的），还要求在RDS 56/57/80三个主流版本上都有同样的体验，从云场景而生并为云场景服务的技术，都是云原生技术。这一目标角度的调整的确是给自己加了不少难度，但研发让所有云上用户都能轻松受益享受技术红利的新技术和功能，仍然让整个AliSQL团队兴奋不已。

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

    • InnoDB Mutex Tuning，InnoDB使用B+ Tree来组织数据，当树的Branch节点需要分裂时，可能会层层向上直到根部，这个分裂是非常昂贵并且难以并发的操作，会严重影响性能。AliSQL在InnoDB的Index Mutex上做了优化，减少了所有页面分列的代价，改进算法优化了分裂的频率和深度，使得TPCC的性能测试提升了35-45%，并且在56/57/80三个版本上都已支持，已在100000+用户的数十万实例上平稳运行一周年多了。

    • 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客户享受到了实实在在的好处。

    • Performance Agent，为了更好地排查性能问题，AliSQL团队研发了一个Performance Agent插件，以秒级频率和完全无锁的方式（相比在SQL中执行show global status命令）输出了数百个性能指标，并且提供了内存视图来查询和分析这些性能数据，使得我们和客户可以基于同一份性能数据来快速高效地分析性能问题。同样在56/57/80三个版本上都实现了Performance Agent，已有100000+用户的数十万实例每秒钟都在记录实时性能数据。

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

    • Binlog In Redo，MySQL为了保证Binlog和InnoDB数据的一至性，使用两阶段XA事务来协调Binlog的落盘和InnoDB Redo Log的落盘，这时每一个事务的提交需要做两次刷盘操作，这对一些对时延（RT，Response Time）敏感的应用，或者使用云盘的实例是不够理想的。AliSQL团队对事务提交过程进行了仔细严谨的梳理，提出了将Binlog写到Redo Log的方案，使得事务提交时不再需要同步Binlog文件，仅需要同步Redo Log，相当于减少了一次落盘操作，从而在保证数据一致性的基础上缩短了事务提交操作的延时，并且提升了事务提交的性能。

    • 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则可以严格限制可以执行删除操作的用户，从权限和目标两个维度进行控制，以帮助大家保障数据安全（需要自行开启）。

    再来提前看一下2020年研发完成还未上线的功能和技术（会在2021年Q1发布上线）:

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

    • Buffer Pool Freely Resize，为了提升RDS的内存弹性，AliSQL团队仔细研究分析了InnoDB Buffer Pool动态调整的逻辑，识别并优化了相关逻辑，使得在线缩减Buffer Pool大小变得基本没有风险，让不重启实例的内存规格弹性在技术上先成为可能。

    • 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%，让客户在同等的资源下可以有更高的性能，为客户切切实实地节约成本。

    • Automatic Hot Queue，这是对电商热杀秒杀功能的一个技术升级，原来需要应用更改SQL传入热点队列的标识，现在则可以自动分析DML语句中的Where条件，如果是PK或UK访问，则自动计算一个热点队列标识，进行并发控制排队，无须应用更改SQL传入热点标识，只需要简简单单地在后台打开开关。

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