优化DDL操作过程中的Buffer Pool管理机制，降低DDL操作带来的性能影响，提升在线DDL操作的并发数。
背景信息
数据库经常会执行DDL操作，也经常会遇到DDL相关的问题，例如：
- 为什么加索引会造成实例的抖动，影响正常的业务读写？
- 为什么不到1 GB的表执行DDL有时需要十几分钟？
- 为什么使用了临时表的连接退出时会造成实例抖动？
针对这些常见问题，RDS内核团队进行分析后发现MySQL在DDL操作期间的缓存维护逻辑存在性能缺陷，通过深入分析及多次测试，开发Faster DDL功能，优化了Buffer Pool页面管理策略，大幅减少DDL操作导致的锁争用，有效解决或缓解上述问题，让您的实例在正常业务压力下可以安心执行DDL操作。
开启Faster DDL
您可以在控制台修改参数loose_innodb_rds_faster_ddl为ON，开启Faster DDL。详情请参见设置实例参数。
DDL场景测试
- 测试场景
选取RDS MySQL 8.0支持的两种In Place Online DDL操作进行验证， 其中CREATE INDEX操作不需要重建表，OPTIMIZE TABLE操作需要重建表。
操作 Instant In Place 重建表 允许并发DML 只修改元数据 CREATE INDEX 否 是 否 是 否 OPTIMIZE TABLE 否 是 是 是 否 - 测试实例
MySQL 8.0实例（8核、64 GB），执行DDL操作的表大小为600 MB。
- 测试过程
使用Sysbench模拟线上业务进行压力测试，在压测期间执行DDL操作，进行反复对比测试。
- 测试结果
操作 平均执行时间（关闭优化） 平均执行时间（开启优化） 性能提升倍数 Create Index 56秒 4.9秒 11.4 Optimize Table 220秒 17秒 12.9 - 测试小结
在DDL场景下，优化后的AliSQL内核MySQL相比社区版本MySQL，DDL操作执行时间缩短了90%以上。
临时表场景测试
MySQL在很多情况下会使用临时表，例如查询information_schema库里的表、 加速复杂SQL执行时自动创建临时表。在线程退出时系统会集中清理用过的临时表，这也属于一种特殊类型的DDL操作，同样会导致实例的性能抖动。 详情请参见Temp ibt tablespace truncation at disconnection stuck InnoDB under large BP。
- 测试实例
MySQL 8.0实例（8核、64 GB）。
- 测试过程
使用tpcc-mysql进行压力测试，将Buff Pool基本用满，然后发起单线程短连接的临时表请求。
- 测试结果
对比项 正常情况（无DDL操作） 开启优化 关闭优化 每秒事务数（TPS） 42,000 40,000 <10,000 压测过程中的秒级性能数据如下图所示（红线处为关闭DDL加速功能）：
- 测试小结
原生MySQL在每次临时表线程退出时出现剧烈的性能抖动，TPS下降超过70%，开启优化之后性能影响降低至5%。
优化效果
Faster DDL加速功能支持RDS MySQL 5.6、5.7、8.0三个版本，但是不同版本支持加速的DDL类型不同，详情请参见下表。
| 分类 | DDL操作 | MySQL 5.6 | MySQL 5.7 | MySQL 8.0 |
|---|---|---|---|---|
| In Place DDL | 详情请参见MySQL 8.0 Online DDL Operations和MySQL 5.7 Online DDL Operations。 | 否 | 是 | 是 |
| 表空间管理 | 开关表空间加密。 | 否 | 是 | 是 |
| 释放或删除表空间。 | 否 | 是 | 是 | |
| 丢弃表空间。 | 是 | 是 | 是 | |
| 删除表 | 释放或删除表。 | 是 | 是 | 是 |
| Undo操作 | 释放或删除undo表空间。 | 否 | 否 | 是 |
| 刷新表 | 刷新表及脏页。 | 是 | 是 | 是 |
Faster DDL解决的缺陷
Faster DDL完美解决了以下MySQL临时缺陷：