优化DDL操作过程中的Buffer Pool管理机制，降低DDL操作带来的性能影响，提升在线DDL操作的并发数。
实例版本如下： 数据库经常会执行DDL操作，也经常会遇到DDL相关的问题，例如： 为什么加索引会造成实例的抖动，影响正常的业务读写？ 为什么不到1 GB的表执行DDL有时需要十几分钟？ 为什么使用了临时表的连接退出时会造成实例抖动？ 针对这些常见问题，RDS内核团队进行分析后发现MySQL在DDL操作期间的缓存维护逻辑存在性能缺陷，通过深入分析及多次测试，开发Faster DDL功能，优化了Buffer Pool页面管理策略，大幅减少DDL操作导致的锁争用，有效解决或缓解上述问题，让您的实例在正常业务压力下可以安心执行DDL操作。 您可以在控制台修改参数loose_innodb_rds_faster_ddl为ON，开启Faster 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完美解决了以下MySQL临时缺陷：前提条件
背景信息
开启Faster DDL
DDL场景测试
临时表场景测试
优化效果
Faster DDL解决的缺陷
