优化背景

DDL是数据库运行期间不可避免的操作，MySQL用户经常会遇到DDL相关的问题包括:

• 为什么加个索引会造成实例的抖动，影响正常的业务读写？
• 为什么一个不到 1G 的表执行 DDL 有时需要十几分钟？
• 为什么使用了 temp table 的连接退出会造成实例抖动？

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

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

测试验证

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

DDL场景

选取 RDS8.0 支持的两种 inplace online ddl 操作进行验证， 其中 create index 操作不需要重建表，optimize teble 操作需要重建表。

测试过程：

测试使用 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: Temp ibt tablespace truncation at disconnection stuck InnoDB under large BP

测试过程：

使用 8c 64g 的 8.0.18 实例正常 tpcc 压测，先提前预热，将 bp 基本用满，并发起单线程短连接的 temp table 请求。

结果对比:

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

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

优化效果

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

DDL加速功能可以缩短表中 DDL 的执行时间，降低 DDL操作对实例运行的影响。

Temp缺陷

1. DDL using bulk load is very slow under long flush_list
2. Temp ibt tablespace truncation at disconnection stuck InnoDB under large BP
3. BUF_REMOVE_ALL_NO_WRITE is not needed for undo tablespace
4. InnoDB temp table could hurt InnoDB perf badly

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