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類型。