• 为什么一个不到 1G 的表执行 DDL 有时需要十几分钟？
  • 为什么使用了 temp table 的连接退出会造成实例抖动？

针对这些问题，RDS内核团队进行分析后发现 MySQL 在 DDL 运行期间的缓存维护逻辑存在性能缺陷。在AliSQL上对这个问题进行了深入分析后，引入了针对性的buffer pool页面管理策略的优化，大大降底DDL操作带来的相关锁争用，解决或有效地缓解了上述问题，让AliSQL在正常业务压力下可以安心地做DDL操作。

启用快速 DDL功能，只需在 RDS 实例上打开 innodb_rds_faster_ddl 参数即可。

这里针对 inplace类型DDL 执行时间， 以及临时表清理两个场景进行压测验证。

测试过程：

测试使用 8c 64g 的 8.0.18 实例进行，执行DDL操作的表大小600M 用sysbench 发起压测请求模拟线上业务，在 sysbench 压测期间执行 DDL 操作，进行反复对比测试。

结果对比:

在该场景下，优化后的AliSQL相比8.0社区版本 DDL 执行时间缩短了90%以上.

临时表场景

MySQL 在很多情况下会使用临时表：查询 information_schema 库下面的表， SQL 中执行 create temporary table 保存中间结果，优化器为了加速某些复杂SQL的执行也会自动创建和删除临时表。在线程退出时会集中清理用到过的临时表，基实是属于一种特殊类型的DDL，同样会导致实例的性能抖动。 更详细的背景有兴趣可以参考这个bug:

测试过程：

结果对比:

原生MySQL在每次 temp table 线程退出时出现剧烈的抖动，tps 下降超过70%，开启优化之后性能影响降低至5%。

压测过程中的秒级性能数据如下图所示（红线处开始关闭DDL加速功能）：

DDL加速功能覆盖 RDS 线上的5.6/5.7/8.0 三个版本，不同版本的性能收益见下表。

  1. DDL using bulk load is very slow under long flush_list
  3. InnoDB temp table could hurt InnoDB perf badly

AliSQL的快速DDL特性（RC_20200630版本）完美地解决了以上MySQL Temp缺陷。