X-Engine是阿里巴巴自研的存儲引擎，作為阿里云 RDS MySQL 的一個可選引擎，除了主打高性能和低成本，還增加了不少惠及用戶的新功能。本文將詳細介紹 MySQL(X-Engine) 如何近乎瞬時完成傳統數據庫需要數小時完成的DDL操作。 ##1.數據庫DDL操作面臨的問題 互聯網業務發展迅速，應用模式頻繁更改是常態。相應地，數據庫訪問模式和schema也隨之變化。DDL（Data Definition Language）是SQL的一類，主要作用是創建和更改數據的schema信息，最常見的操作包括：加減列、更改列類型、加減索引等。

熟悉MySQL的同學都知道，在8.0以前，雖然Online DDL不阻塞其它DML（Insert/Update/Delete）操作，但許多重要的DDL操作，如加列、減列等，仍舊需要等待數小時、甚至好幾天時間（依據數據量的大小）才會生效。更改列類型等操作甚至仍需要鎖表執行，阻塞DML操作。 DDL操作運行時間長，占用系統資源，需要額外的磁盤空間（建立臨時表），影響系統吞吐，并且一旦DDL過程中實例crash，恢復時間也會很久。以加列DDL為例，MySQL經歷如下過程： ``` 

1.以新schema建立空表。 

2.拷貝數據到新表，并且將新加列的值賦為默認值，同時更新索引表。數據庫接受到的DML操作被記錄在臨時文件。 

3.加exclusive lock，阻塞寫操作，將臨時文件記錄的DML操作apply到新表。如果DML很多，這一階段將花費較多時間。

4.刪除舊表，將新表命名為舊表的名字。 

``` 顯然，這個過程加鎖時間長，拷貝數據操作會占用系統資源和臨時空間，并需要大量I/O。為了適應變化頻繁的業務，不立即更改存儲層數據、可以快速完成的DDL（我們稱之為Fast DDL）成為了一個必要feature。

MySQL 8.0 增加了instant add column功能，可以在短時間內只修改table元信息，完成加列操作。遺憾的是，它還不支持其它類型的DDL。得益于阿里自研的存儲引擎X-Engine存儲了多版本Table Schema，每一行記錄在引擎層就完成了解析，并且可以依據更新版本的schema實現格式轉換，X-Engine因此可支持多種類型的Fast DDL。 

2.業界Fast ddl實現方案 **MySQL 8.0** record記錄了列個數, instant add column操作只修改系統表。 寫操作：新格式的記錄。 讀操作：根據存儲在系統表中default value補齊新加列。 支持類型： ? Change index optionRename table ? Set/drop default ? Modify column when the table is empty ? Add/drop virtual columnsAdd columns **MariaDB10.3** 整體實現方案與MySQL8.0類似，record記錄了列個數，在leftmost leaf page中記錄所有列的default值. 支持類型： ? Add column ? Drop column ? Extend VARCHAR maximum （Only if the physical format allows; not VARCHAR(255) to VARCHAR(256)） 

Aurora** 發生ddl后，更新系統表，新、舊版本的schema均要記錄下來。然后廣播該修改。之后接受DML請求，首先轉換相關leaf page的所有記錄，然后執行DML。 select請求會將舊版本的記錄拼接成新版本記錄。 支持類型 ? only supports adding nullable columns, without default values ##3.X-Engine多版本schema 顧名思義，Fast DDL指數據庫能夠在極短的時間內完成用戶發出的DDL指令并返回。之所以這么快，是因為只修系統表里的元數據，不變更引擎層存儲的數據。其實現的關鍵在于：元信息變更之后，內存、磁盤中的物理記錄該如何解析。 Engine的架構采用了LSM-Tree的思想，將新寫入的數據以追加方式寫入內存memtable，memtable到一定大小后switch為immutable memtable，不再修改。然后逐漸以固定大小extent的形式，flush到持久化存儲中。

當extent到一定數量后，通過合并(Compaction)操作，將相同Key的多個版本合并。為了讓每行記錄可解析，最直觀簡單的方案便是將元信息附著在記錄上面。為了能夠不依賴系統表解析記錄，X-Engine存儲了較為詳細的元數據，如果為每一行都附著一份，會占用大量的空間。為了大大減少存儲成本，我們保證每個memtable和extent內部的數據schema一致，并將schema信息存儲在memtable和extent之上。 schema信息包含了諸如列個數、列類型、列長度、默認值等關鍵信息。利用這些信息，X-Engine可以在返回結果之前，完成列解析，并只需返回查詢目標列的對應結果。下面給出了一個具體的例子，同一張表存在不同schema版本的extent時，如何返回結果。 

4.X-Engine fast ddl實現 當 MySQL 接收到一條fast ddl語句時，更新相關系統表及元數據，新版本的表結構隨之生效，這時這條DDL語句就執行成功啦！到現在為止X-Engine存儲的信息沒有發生任何變化。 **讀請求** 當系統接收到Select請求時，MySQL 會將請求本身，連同當前最新版本schema信息（稱之為target schema）傳遞到X-Engine。X-Engine首先定位到記錄的位置（某個memtable或extent），并取相應數據schema解析記錄得到初步結果。接著，對比數據schema和target schema，對初步結果做適當填充、刪減或修改得到最終結果返回。 **X-Engine schema更新** Fast DDL命令執行成功，新版本的schema生效，X-Engine還對此無感知。當接收到第一條針對該表的DML（Insert/Update/ Delete）請后，如果發現X-Engine的活躍memtable的schema版本落后于最新版本，會觸發switch memtable行為：凍結當前活躍memtable，產生新活躍memtable，將新schema賦予新活躍memtable。為了保證數據的正確性，該操作會等待所有正在進行的寫事務完成后再執行。 

寫請求

 每個寫事務可能涉及到n（n>=1）個表。事務在提交時，需要在寫入活躍memtable之前判斷：事務寫入數據的schema版本是否與活躍memtable的schema版本一致，如果不一致則應該報錯退出，提醒用戶重試。 **Flush/Compaction** 內存中memtable數量到一定個數時會觸發Flush操作，被選中memtable的數據以extent的形式寫入磁盤，schema也隨之由memtable傳遞到extent。Compaction操作會合并多個extent，如果參與同一任務的extent schema版本不一致，X-Engine會以其中最新版本為準，生成新extent。

總結 Fast DDL可以解決很多應用的痛點，加列、擴展列的常用的操作不用再需要漫長的等待。技術上，X-Engine通過存儲詳細的多版本schema信息，不僅無需借助系統表解析記錄，而且可以輕易地實現不同版本schema之間的數據轉換，進而可以支持豐富的Fast DDL類型。