我們先來復習壹下，在沒有“立即添加列”功能的情況下，如何添加列。我們也借此機會熟悉壹下這個問題的由來:
添加列時，所有數據行都必須添加壹條數據(圖中第4列數據)。
如上圖所述，當數據行的長度發生變化時，需要重建表空間(圖中灰藍色的部分就是發生變化的部分)。
數據字典中的列定義也會更新。
上述操作的問題在於，每次添加壹列，都需要重建表空間，這需要大量的IO和大量的時間。
立即添加列
“立即添加列”的過程如下:
請點擊輸入圖片說明。
請點擊輸入圖片說明。
"立即添加列"只會改變數據字典的內容，包括:
向列定義中添加新的列定義。
增加新列的默認值
“立即添加”？稍後，當您想要讀取表中的數據時:
因為“立即添加列”沒有更改行數據，所以只讀取了3行行數據。
MySQL會將新添加的第四列的默認值追加到讀取的數據中。
上面的過程描述了如何閱讀。“馬上加列”之前寫數據的本質是:在讀取數據的過程中“偽造”？做了壹個新的列表。
那麽怎麽讀呢？在“立即添加”之後？書面數據呢？流程如下:
當讀取第4行時:
請點擊輸入圖片說明。
請點擊輸入圖片說明。
憑判斷？即時在數據行的表頭信息？標誌，就可以知道該行的格式是“新格式”:該行的表頭信息後有壹個新字段？"列數"
通過閱讀？數據線？“列數”？字段，可以知道這壹行數據中有多少列有“真實”的數據，以便根據列數讀取數據。
從上圖可以看出:讀？在“立即添加”？之前/之後寫入的數據是不同的過程。
通過以上討論，我們可以總結出？“立即添加”？它高效的原因是:
正在執行嗎？“立即添加”？不會更改數據行的結構。
在讀取“舊”數據時，“偽造”？添加新行以使結果正確。
當寫入“新”數據時，使用新的數據格式(即時標誌位和？“列數”？字段)來區分新舊數據。
在讀取“新”數據時，可以如實讀取數據。
那又怎樣？還能繼續鍛造嗎？下去“鍛造”？什麽時候曝光？
考慮以下場景:
用“立即添加列”添加列a
寫數據線1
用“立即添加列”添加列？B
寫數據行？2
刪除列？B
我們來猜測壹下“刪除b列”的最小代價:需要修改數據行的即時標誌位還是？“列數”？場，這至少會影響？“立即添加”？稍後寫入的數據行的開銷與重建數據的開銷類似。
從上面的推測中，我們可以知道什麽時候與有關系？“立即添加”？當操作不兼容的DDL操作時，需要重建數據表，如下圖所示:
請點擊輸入圖片說明。
請點擊輸入圖片說明。
延伸思考問題:可以設計其他數據格式代替即時標誌和嗎？“列數”？字段，以便添加/刪除列可以“壹次完成”？(提示:考慮添加列？-刪除列？-在額外上市的情況下)
使用限制
了解了原理之後，我們來看看吧？“立即添加”？限制的使用，很容易理解前兩個:
“立即添加”？的列添加位置只能在表尾，不能在其他列之間添加。
在元數據中，只記錄數據行中的列數，而不記錄這些列應該出現的位置。無法找到指定列的位置。
“立即添加”？無法添加主鍵列。
添加列不能涉及聚集索引的更改，否則它將成為“重建”操作，而不是“立即”完成。
“立即添加列”不支持壓縮表格式。
根據WL的說法，“壓縮是不需要支持的”(不需要支持不常用的格式)。
總結和回顧
讓我們總結壹下上面的討論:
“立即添加列”很有效，因為:
當執行“立即添加列”時，數據行的結構不會改變。
在讀取“舊”數據時，“偽造”？添加新行以使結果正確。
當寫“新”數據時，妳使用了新的數據格式嗎？(增加了？即時標誌？和“列數”字段)來區分新舊數據。
在讀取“新”數據時，可以如實讀取數據。
“立即添加”？“偽造”的方法不可能永遠存在。當它發生的時候？與“立即添加列”操作不兼容？DDL？，將重建表數據。
回到之前遺留的兩個問題:
“立即添加”是如何工作的？
這個問題我們已經回答了。
所謂的“壹下子加列”是不是壹點都不影響業務，真的是“馬上”完成？
由此可見，即使立即添加列，也需要更改數據字典，因此其上的鎖無法逃脫。也就是說，這裏的“立即”是指“不改變數據行的結構”，而不是“零成本完成任務”