優化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臨時缺陷：