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