优化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_ddlON,开启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加速功能):

    TPS性能
  • 测试小结

    原生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 OperationsMySQL 5.7 Online DDL Operations
表空间管理 开关表空间加密。
释放或删除表空间。
丢弃表空间。
删除表 释放或删除表。
Undo操作 释放或删除undo表空间。
刷新表 刷新表及脏页。

Faster DDL解决的缺陷

Faster DDL完美解决了以下MySQL临时缺陷: