在上一期圖解?圖解MySQL | MySQL DDL為什么成本高？中，我們介紹了：
傳統情況下，為表添加列需要對表進行重建
騰訊團隊為 MySQL 引入了 Instant Add Column 的方案(以下稱為 "立刻加列" 功能)可以快速完成 為表添加列 的任務
同時我們留了以下思考題：
"立刻加列" 是如何工作的 ?
所謂 "立刻加列" 是否完全不影響業務，是否是真正的 "立刻" 完成 ?
本期我們針對這幾個問題來進行討論：
傳統情況
我們先回顧一下，在沒有 "立刻加列" 功能時，加列操作是怎么完成的。我們也借此來熟悉一下本期的圖例：
當進行 加列操作 時，所有的數據行 都必須要 增加一段數據(圖中的 列 4 數據)
如上一期圖解所講，當改變數據行的長度，就需要 重建表空間(圖中灰藍的部分為發生變更的部分)
數據字典中的列定義也會被更新
以上操作的問題在于 每次加列 操作都需要重建表空間，這就需要大量 IO以及大量的時間
立刻加列
"立刻加列" 的過程如下圖：
"立刻加列" 時，只會變更數據字典中的內容，包括：
在列定義中增加 新列的定義
增加 新列的默認值
"立刻加列"?后，當要讀取表中的數據時：
由于 "立刻加列" 沒有 變更行數據，讀取的行數據只有 3 列
MySQL 會將 新增的第 4 列的默認值，追加到 讀取的數據后
以上過程描述了 如何讀取 在 "立刻加列" 之前寫入的數據，其實質是：在讀取數據的過程中，"偽造"?了一個新列出來
那么如何讀取 在 "立刻加列" 之后 寫入的數據呢 ? 過程如下圖：
當讀取 行 4 時：
通過判斷 數據行的頭信息中的instant 標志位，可以知道該行的格式是 "新格式"：該行頭信息后有一個新字段 "列數"
通過讀取?數據行的 "列數" 字段，可以知道 該行數據中多少列有 "真實" 的數據，從而按列數讀取數據
通過上圖可以看到：讀取?在"立刻加列"?前/后寫入的數據是不同的流程
通過以上的討論，我們可以總結 "立刻加列" 之所以高效的原因是：
在執行 "立刻加列" 時，不變更數據行的結構
讀取 "舊" 數據時，"偽造"?新增的列，使結果正確
寫入 "新" 數據時，使用了新的數據格式(增加了instant標志位 和 "列數" 字段)，以區分新舊數據
讀取 "新" 數據時，可以如實讀取數據
那么?我們是否能一直 "偽造" 下去???"偽造" 何時會被拆穿 ?
考慮以下場景：
用 "立刻加列" 增加列 A
寫入數據行 1
用 "立刻加列" 增加列?B
寫入數據行?2
刪除列?B
我們推測一下 "刪除列 B" 的最小代價：需要修改 數據行中的instant標志位或 "列數" 字段，這至少會影響到?"立刻加列" 之后寫入的數據行，成本類似于重建數據
從以上推測可知：當出現 與 "立刻加列" 操作不兼容 的 DDL 操作時，數據表需要進行重建，如下圖所示：
擴展思考題：是否能設計其他的數據格式，取代instant標志位和 "列數" 字段，使得 加列/刪列 操作都能 "立刻完成" ?(提示：考慮 加列?- 刪列?- 再加列 的情況)
使用限制
在了解原理之后，我們來看看 "立刻加列" 的使用限制，就很容易能理解其中的前兩項：
"立刻加列"?的加列位置只能在表的最后，而不能加在其他列之間在元數據中，只記錄了 數據行 應有多少列，而沒有記錄 這些列 應出現的位置。所以無法實現指定列的位置
"立刻加列"?不能添加主鍵列加列 不能涉及聚簇索引的變更，否則就變成了 "重建" 操作，不是 "立刻" 完成了
"立刻加列"不支持壓縮的表格式
按照 WL 的說法："COMPRESSED is no need to supported"(沒必要支持不怎么用的格式)
總結回顧
我們總結一下上面的討論：
"立刻加列" 之所以高效的原因是：
在執行 "立刻加列" 時，不變更數據行的結構
讀取 "舊" 數據時，"偽造"?新增的列，使結果正確
寫入 "新" 數據時，使用了新的數據格式?(增加了?instant 標志位?和 "列數" 字段)，以區分新舊數據
讀取 "新" 數據時，可以如實讀取數據
"立刻加列"?的 "偽造" 手法，不能一直維持下去。當發生?與 "立刻加列" 操作不兼容 的 DDL?時，表數據就會發生重建
回到之前遺留的兩個問題：
"立刻加列" 是如何工作的 ?
我們已經解答了這個問題
所謂 "立刻加列" 是否完全不影響業務，是否是真正的 "立刻" 完成 ?
可以看到：就算是 "立刻加列"，也需要變更 數據字典，那么 該上的鎖還是逃不掉的。也就是說 這里的 "立刻" 指的是 "不變更數據行的結構"，而并非指 "零成本地完成任務"
本期仍然留下一個思考題：
本文中描述了?在 "立刻加列" 之后?插入?數據行的情況?(數據行會使用新格式)。那么在 "立刻加列" 之后 更新?數據行會發生什么情況呢??
圖解MySQL原理
圖解MySQL | MySQL DDL為什么成本高？
圖解MySQL?|?[原理解析]?XtraBackup增量備份還原
[原理解析]?XtraBackup全量備份還原
[原理解析]?MySQL使用固定的server_id導致數據丟失
[原理解析]?MySQL組提交(group?commit)
[原理解析]?設置字符集的參數控制了哪些行為
近期社區動態
第三期 社區技術內容征稿?
所有稿件，一經采用，均會為作者署名。
征稿主題：MySQL、分布式中間件DBLE、數據傳輸組件DTLE相關的技術內容
活動時間：2019年6月11日 - 7月11日
本期投稿獎勵
投稿成功：京東卡200元*1
優秀稿件：京東卡200元*1+社區定制周邊(包含：定制文化衫、定制傘、鼠標墊)
優秀稿件評選，文章獲得“好看”數量排名前三的稿件為本期優秀稿件。
喜歡點“分享”，不行就“在看”
多喝熱水，重啟試試
