傳統(tǒng)情況
格爾木網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),格爾木網(wǎng)站設(shè)計(jì)制作,有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為格爾木上1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢,請找那個(gè)售后服務(wù)好的格爾木做網(wǎng)站的公司定做!
我們先回顧一下,在沒有 "立刻加列" 功能時(shí),加列操作是怎么完成的。我們也借此來熟悉一下本期的圖例:
當(dāng)進(jìn)行 加列操作 時(shí),所有的數(shù)據(jù)行 都必須要 增加一段數(shù)據(jù)(圖中的 列 4 數(shù)據(jù))
如上一期圖解所講,當(dāng)改變數(shù)據(jù)行的長度,就需要 重建表空間(圖中灰藍(lán)的部分為發(fā)生變更的部分)
數(shù)據(jù)字典中的列定義也會(huì)被更新
以上操作的問題在于 每次加列 操作都需要重建表空間,這就需要大量 IO以及大量的時(shí)間
立刻加列
"立刻加列" 的過程如下圖:
請點(diǎn)擊輸入圖片描述
請點(diǎn)擊輸入圖片描述
"立刻加列" 時(shí),只會(huì)變更數(shù)據(jù)字典中的內(nèi)容,包括:
在列定義中增加 新列的定義
增加 新列的默認(rèn)值
"立刻加列"?后,當(dāng)要讀取表中的數(shù)據(jù)時(shí):
由于 "立刻加列" 沒有 變更行數(shù)據(jù),讀取的行數(shù)據(jù)只有 3 列
MySQL 會(huì)將 新增的第 4 列的默認(rèn)值,追加到 讀取的數(shù)據(jù)后
以上過程描述了 如何讀取?在 "立刻加列" 之前寫入的數(shù)據(jù),其實(shí)質(zhì)是:在讀取數(shù)據(jù)的過程中,"偽造"?了一個(gè)新列出來
那么如何讀取?在 "立刻加列" 之后?寫入的數(shù)據(jù)呢 ? 過程如下圖:
當(dāng)讀取 行 4 時(shí):
請點(diǎn)擊輸入圖片描述
請點(diǎn)擊輸入圖片描述
通過判斷?數(shù)據(jù)行的頭信息中的instant?標(biāo)志位,可以知道該行的格式是 "新格式":該行頭信息后有一個(gè)新字段?"列數(shù)"
通過讀取?數(shù)據(jù)行的?"列數(shù)"?字段,可以知道 該行數(shù)據(jù)中多少列有 "真實(shí)" 的數(shù)據(jù),從而按列數(shù)讀取數(shù)據(jù)
通過上圖可以看到:讀取?在"立刻加列"?前/后寫入的數(shù)據(jù)是不同的流程
通過以上的討論,我們可以總結(jié)?"立刻加列"?之所以高效的原因是:
在執(zhí)行?"立刻加列"?時(shí),不變更數(shù)據(jù)行的結(jié)構(gòu)
讀取 "舊" 數(shù)據(jù)時(shí),"偽造"?新增的列,使結(jié)果正確
寫入 "新" 數(shù)據(jù)時(shí),使用了新的數(shù)據(jù)格式(增加了instant標(biāo)志位 和?"列數(shù)"?字段),以區(qū)分新舊數(shù)據(jù)
讀取 "新" 數(shù)據(jù)時(shí),可以如實(shí)讀取數(shù)據(jù)
那么?我們是否能一直 "偽造"?下去???"偽造"?何時(shí)會(huì)被拆穿 ?
考慮以下場景:
用 "立刻加列" 增加列 A
寫入數(shù)據(jù)行 1
用 "立刻加列" 增加列?B
寫入數(shù)據(jù)行?2
刪除列?B
我們推測一下 "刪除列 B" 的最小代價(jià):需要修改 數(shù)據(jù)行中的instant標(biāo)志位或?"列數(shù)"?字段,這至少會(huì)影響到?"立刻加列"?之后寫入的數(shù)據(jù)行,成本類似于重建數(shù)據(jù)
從以上推測可知:當(dāng)出現(xiàn) 與?"立刻加列"?操作不兼容 的 DDL 操作時(shí),數(shù)據(jù)表需要進(jìn)行重建,如下圖所示:
請點(diǎn)擊輸入圖片描述
請點(diǎn)擊輸入圖片描述
擴(kuò)展思考題:是否能設(shè)計(jì)其他的數(shù)據(jù)格式,取代instant標(biāo)志位和?"列數(shù)"?字段,使得 加列/刪列 操作都能 "立刻完成" ?(提示:考慮 加列?- 刪列?- 再加列 的情況)
使用限制
在了解原理之后,我們來看看?"立刻加列"?的使用限制,就很容易能理解其中的前兩項(xiàng):
"立刻加列"?的加列位置只能在表的最后,而不能加在其他列之間
在元數(shù)據(jù)中,只記錄了 數(shù)據(jù)行 應(yīng)有多少列,而沒有記錄 這些列 應(yīng)出現(xiàn)的位置。所以無法實(shí)現(xiàn)指定列的位置
"立刻加列"?不能添加主鍵列
加列 不能涉及聚簇索引的變更,否則就變成了 "重建" 操作,不是 "立刻" 完成了
"立刻加列"不支持壓縮的表格式
按照 WL 的說法:"COMPRESSED is no need to supported"(沒必要支持不怎么用的格式)
總結(jié)回顧
我們總結(jié)一下上面的討論:
"立刻加列" 之所以高效的原因是:
在執(zhí)行 "立刻加列" 時(shí),不變更數(shù)據(jù)行的結(jié)構(gòu)
讀取 "舊" 數(shù)據(jù)時(shí),"偽造"?新增的列,使結(jié)果正確
寫入 "新" 數(shù)據(jù)時(shí),使用了新的數(shù)據(jù)格式?(增加了?instant 標(biāo)志位?和 "列數(shù)" 字段),以區(qū)分新舊數(shù)據(jù)
讀取 "新" 數(shù)據(jù)時(shí),可以如實(shí)讀取數(shù)據(jù)
"立刻加列"?的 "偽造" 手法,不能一直維持下去。當(dāng)發(fā)生?與 "立刻加列" 操作不兼容?的 DDL?時(shí),表數(shù)據(jù)就會(huì)發(fā)生重建
回到之前遺留的兩個(gè)問題:
"立刻加列" 是如何工作的 ?
我們已經(jīng)解答了這個(gè)問題
所謂 "立刻加列" 是否完全不影響業(yè)務(wù),是否是真正的 "立刻" 完成 ?
可以看到:就算是 "立刻加列",也需要變更 數(shù)據(jù)字典,那么 該上的鎖還是逃不掉的。也就是說 這里的 "立刻" 指的是 "不變更數(shù)據(jù)行的結(jié)構(gòu)",而并非指 "零成本地完成任務(wù)"
以插入語句的方法來解決此問題。
如下參考:
1.在添加字段之前,第一個(gè)zd應(yīng)該首先檢查tb1表的當(dāng)前結(jié)構(gòu)。
2.將字段列instance添加到表中,如下圖。
3.再次查看表結(jié)構(gòu),比較添加字段之前和之后的情況。
4.最后,插入新的數(shù)據(jù)行,看看它是什么樣子,最后就加入了自動(dòng)增長字段如下圖。
注意事項(xiàng):
MySQL使用的SQL語言是訪問數(shù)據(jù)庫最常用的標(biāo)準(zhǔn)化語言。MySQL軟件采用雙重許可政策,分為社區(qū)版和商業(yè)版,由于其體積小,速度快,整體擁有成本低,尤其是開源這一特點(diǎn),一般中小型網(wǎng)站開發(fā)都選擇MySQL作為網(wǎng)站數(shù)據(jù)庫。
這樣會(huì)默認(rèn)在表的最后增加一個(gè)auth字段,如果你想在開頭添加,你可以這樣寫:
在中間增加:
語法:
以上,如有紕漏,歡迎指正。