本文雲端式原生資料庫PolarDB MySQL版,對常見DDL的操作進行了說明,方便使用者查詢和瞭解DDL的行為,評估DDL操作風險,降低對業務的影響。
DDL操作說明
在MySQL生態中,DDL是一類非常複雜的操作,包括Index操作、Primary Key操作、Column操作、Table操作、Foreign Key操作、Generated Column操作等多種不同類型的操作。DDL操作不僅耗時間長度、消耗硬體資源多,而且其中涉及鎖表操作,操作不當就可能影響正常業務,造成災難性的影響。
PolarDB MySQL版的DDL模組經過多年的經驗積累和持續的功能迭代,在效能和鎖穩定性方面取得了長足的進步。本文將從如下幾個方面介紹PolarDB MySQL版的各個版本常見的DDL操作的行為特徵:
是否鎖表(允許並發DML):非鎖表的DDL(Online DDL)只在修改中繼資料時申請表互斥鎖(期間一般不超過1秒),在表結構變更期間允許對目標表進行讀寫操作,提高了在生產環境中的響應速度和可用性。相反,不支援Online DDL功能的語句會全程鎖表,不支援並發的寫入操作,當DDL操作期間較長時,可能會對業務操作造成重大影響。
是否重建表(期間長短):此類DDL需要根據新的表結構重新建立Primary Key以及所有二級索引,通常需要花費較長時間。
說明由於PolarDB MySQL版支援並行DDL功能,使用核心方式執行DDL的效能遠優於使用gh-ost/pt-osc等第三方工具時的效能。
是否只修改中繼資料(秒級完成):只修改中繼資料,無需修改表資料。此類DDL操作的執行時間不會隨著表規模的變大而變長,一般秒級完成。
是否支援並行DDL(多線程加速):對於在大表上建立索引、重建表等情境,PolarDB支援通過並行DDL,使用多線程提升DDL的執行效率,最高可提升15~20倍的效能。詳細內容請查看並行DDL的說明文檔。
是否影響效能(無鎖變更):無鎖變更工單實現無鎖結構變更不會產生閃斷,在業務低穀時不會影響業務。
說明建議您在業務低穀期進行操作,該操作可能會導致IOPS和CPU的上升。
DDL執行演算法
PolarDB MySQL版支援以下三種DDL執行演算法:
INSTANT演算法: 使用INSTANT演算法執行DDL操作時,只需要修改資料字典中的中繼資料,不需要修改或複製存量資料,也不需要重建表。因此其不受表的大小影響,整個DDL過程可以秒級完成。
INPLACE演算法:使用INPLACE演算法時,表中資料的複製和重建都是在引擎內部完成,執行速度會更快。同時,絕大部分使用INPLACE演算法執行的DDL允許並發讀寫訪問,對業務的影響較小。此外,部分採用INPLACE演算法執行的DDL,如RENAME TABLE、ADD COMMENT等可以做到僅修改元資訊,不修改表中資料,可以做到秒級完成。
COPY演算法:當使用COPY演算法執行DDL操作時,需要將表中所有的資料複製到新表中。在資料複製期間,會持有原表的SNW(SHARED_NO_WRITE)鎖。因此,在執行DDL操作期間僅支援讀操作,不允許執行並發寫入操作,對業務影響較大。
其中,允許並發讀寫操作的DDL操作被統稱為Online DDL。Online DDL對業務的影響相對較小。通常情況下,使用者無需手動指定DDL使用的演算法,PolarDB會自動按照INSTANT、INPLACE、COPY的順序選擇最佳的演算法。此外,您也可以使用ALTER TABLE語句的ALGORITHM和LOCK子句對DDL的行為做精細化管理:
ALGORITHM子句:為了使用指定演算法執行DDL語句,您可以指定ALGORITHM欄位,可選的值有DEFAULT、INSTANT、INPLACE和COPY。當DDL操作不支援該演算法時,會立即返回報錯。
LOCK子句:LOCK子句用於調整執行DDL期間對錶的並發訪問。您可以使用該LOCK子句來控製表被更改時的並發讀寫層級,可配置的選項及含義介紹如下:
DEFAULT:核心根據不同的DDL類型,允許最大程度的並發讀取和寫入。
NONE:允許在執行DDL期間進行並發讀取和寫入。如果不支援,則返回錯誤。
SHARED:允許並發讀取但阻止寫入。如果不支援並發讀取,則返回錯誤。
EXCLUSIVE:禁止在執行DDL操作期間的一切並發讀取和寫入操作。
為了防止在執行ALTER TABLE期間出現表不可訪問的情況,您可以在ALTER TABLE語句中指定LOCK子句。即如果DDL執行時的鎖行為不滿足給定條件時,操作就會被立即停止。
使用EXPLAIN DDL功能預覽DDL執行特徵
本文檔列出了常見DDL操作的執行特徵。然而,由於PolarDB功能豐富,實際的DDL執行行為可能會受到多種因素的影響,例如目標表的結構、執行個體參數配置,或是否啟用了某些特定功能等。
為提升結構變更的安全性與可預測性,強烈建議您在執行複雜DDL操作前,使用EXPLAIN DDL功能,提前瞭解DDL操作的執行特徵。
使用如下文法即可查看 DDL 的執行特徵:
{ EXPLAIN | DESCRIBE | DESC } ALTER TABLE ...通過EXPLAIN DDL,您可以擷取以下關鍵資訊:
當前DDL操作是否可以執行成功。
當前DDL操作所使用的演算法類型,取值為:
INSTANT、INPLACE和COPY。當前DDL操作是否需要重建整張表的資料(重建全表通常耗時較長)。
當前DDL執行期間是否允許並發的DML操作。
當前DDL操作是否會被未提交的事務阻塞。
當前DDL操作是否支援並行DDL加速(如支援,將展示當前DDL操作的並行度)。
通過提前瞭解這些資訊,您可以更準確地評估DDL的影響,合理選擇執行時機,有效避免鎖表、執行時間過長等對線上業務造成的影響。詳情請參見EXPLAIN DDL。
DDL行為特徵
Index操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
建立二級索引 | 是 | 否 | 否 | 支援 |
刪除二級索引 | 是 | 否 | 是 | 不涉及 |
重新命名二級索引 | 是 | 否 | 是 | 不涉及 |
增加全文索引(FULLTEXT) | 否 | 否 說明 在添加表的第一個全文索引時,如果沒有使用者定義的FTS_DOC_ID列,會導致額外的重建表操作。 | 否 | 不支援 |
增加空間索引(SPATIAL) | 否 | 否 | 否 | 不支援 |
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
建立二級索引 | 是 | 否 | 否 | 支援 |
刪除二級索引 | 是 | 否 | 是 | 不涉及 |
重新命名二級索引 | 是 | 否 | 是 | 不涉及 |
增加全文索引(FULLTEXT) | 否 | 否 說明 在添加表的第一個全文索引時,如果沒有使用者定義的FTS_DOC_ID列,會導致額外的重建表操作。 | 否 | 不支援 |
增加空間索引(SPATIAL) | 否 | 否 | 否 | 不支援 |
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
建立二級索引 | 是 | 否 | 否 | 支援 |
刪除二級索引 | 是 | 否 | 是 | 不涉及 |
重新命名二級索引 | 是 | 否 | 是 | 不涉及 |
增加全文索引(FULLTEXT) | 否 | 否 說明 在添加表的第一個全文索引時,如果沒有使用者定義的FTS_DOC_ID列,會導致額外的重建表操作。 | 否 | 不支援 |
增加空間索引(SPATIAL) | 否 | 否 | 否 | 不支援 |
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
建立二級索引 | 是 | 否 | 否 | 不支援 |
刪除二級索引 | 是 | 否 | 是 | 不涉及 |
重新命名二級索引 | 是 | 否 | 是 | 不涉及 |
增加全文索引(FULLTEXT) | 否 | 否 說明 在添加表的第一個全文索引時,如果沒有使用者定義的FTS_DOC_ID列,會導致額外的重建表操作。 | 否 | 不支援 |
增加空間索引(SPATIAL) | 否 | 否 | 否 | 不支援 |
Primary Key操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Primary Key | 是 | 是 | 否 | 支援 |
刪除Primary Key | 否 | 是 | 否 | 不支援 |
刪除原來的Primary Key,增加新的Primary Key | 是 | 是 | 否 | 支援 |
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Primary Key | 是 | 是 | 否 | 支援 |
刪除Primary Key | 否 | 是 | 否 | 不支援 |
刪除原來的Primary Key,增加新的Primary Key | 是 | 是 | 否 | 支援 |
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Primary Key | 是 | 是 | 否 | 支援 |
刪除Primary Key | 否 | 是 | 否 | 不支援 |
刪除原來的Primary Key,增加新的Primary Key | 是 | 是 | 否 | 支援 |
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Primary Key | 是 | 是 | 否 | 不支援 |
刪除Primary Key | 否 | 是 | 否 | 不支援 |
刪除原來的Primary Key,增加新的Primary Key | 是 | 是 | 否 | 不支援 |
在以下情境中,僅當叢集參數sql_mode包含STRICT_TRANS_TABLES或STRICT_ALL_TABLES時,才允許並發DML:
增加Primary Key
刪除原來的Primary Key,增加新的Primary Key
Column操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加列 | 是 | 否1 | 是1 | 支援1 |
刪除列 | 是 | 是 | 否 | 支援 |
重新命名列 | 是 | 否 | 是 | 不涉及 |
重排序列 | 是 | 是 | 否 | 支援 |
設定列的預設值 | 是 | 否 | 是 | 不涉及 |
修改列注釋 | 是 | 否 | 是 | 不涉及 |
修改列類型 | 否 | 是 | 否 | 不支援 |
擴充VARCHAR長度 | 是2 | 否 | 是 | 不涉及 |
將UTF8mb3字元集修改為UTF8mb4字元集 | 否 | 否3 | 是3 | 不支援 |
刪除列預設值 | 是 | 否 | 是 | 不涉及 |
修改auto-increment值 | 是 | 否 | 是 | 不涉及 |
變更某列為NULL | 是 | 是 | 否 | 支援 |
變更某列為非NULL | 否 | 是 | 否 | 不支援 |
修改ENUM/SET列的定義 | 是 | 否 | 是4 | 不涉及 |
秒級加欄位功能僅支援將列添加至表的末尾。當表未指定主鍵時,需要將參數
implicit_primary_key的值設定為OFF,以避免在執行秒級加欄位操作時因表的最末尾的隱式主鍵列導致加列操作失敗。除此之外,不支援在壓縮表(ROW_FORMAT=COMPRESSED)、帶有全文索引的表以及暫存資料表上執行秒級加欄位操作。如果叢集不支援使用秒級加欄位功能,增加欄位將使用INPLACE方式執行DDL。此時需要進行全表重建,重建期間允許並發讀寫操作。您也可以通過並行DDL功能進行加速。擴充VARCHAR長度時,儲存VARCHAR列長度所需的位元組數需要保持一致,才能支援快速列擴充。具體來說,對於0~255個位元組的VARCHAR列,只需要一個Byte儲存長度。而對於大於等於256位元組的VARCHAR列,就需要兩個Bytes儲存長度。只有控制VARCHAR列長度的擴充範圍,比如從0~255位元組或從256位元組擴充到更大的範圍,才能保證在執行ALTER TABLE時只修改中繼資料。即當修改VARCHAR列的長度從小於256位元組擴充到大於等於256位元組的長度時,PolarDB預設使用Copy DDL,即全程鎖表,不支援DML寫操作,僅支援讀操作。
當您不確定自己修改VARCHAR列的範圍是否滿足上述條件時,可以使用
ALGORITHM=INPLACE指定採用INPLACE演算法執行當前DDL操作。此時,如果不支援快速列擴充,則會直接報錯。樣本如下:ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256); ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.VARCHAR類型屬於變長儲存類型,磁碟僅儲存實際長度,因此建議您在使用VARCHAR類型的欄位時,考慮將最大長度直接調整到256個位元組及以上,以避免在擴充欄位時可能需要使用COPY演算法。
當滿足以下條件時,將列的字元集從UTF8mb3修改至UTF8mb4僅修改中繼資料,無需修改資料。否則,需要使用COPY演算法進行表重建,且重建期間全程鎖表,目標表只能讀,不能執行寫入操作。
列類型為CHAR、VARCHAR、ENUM以及TEXT類型。
修改的列上不存在任何索引。
字元集轉換前後,列的最大儲存長度均小於256或均大於255。
您可以通過指定ALGORITHM=INPLACE來強制使用非重建表的方式執行DDL,如果需要使用COPY演算法才能執行時,會立刻返回報錯。樣本如下:
ALTER TABLE test modify column b char(1) CHARACTER SET utf8mb4 default null,algorithm = inplace; ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.僅當資料類型的儲存大小不發生改變,且向ENUM或SET的末尾追加元素時,才可以僅修改中繼資料,不重建整張表。否則需要使用COPY演算法進行表重建。
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加列 | 是 | 否1 | 是1 | 支援1 |
刪除列 | 是 | 是 | 否 | 支援 |
重新命名列 | 是 | 否 | 是 | 不涉及 |
重排序列 | 是 | 是 | 否 | 支援 |
設定列的預設值 | 是 | 否 | 是 | 不涉及 |
修改列注釋 | 是 | 否 | 是 | 不涉及 |
修改列類型 | 否 | 是 | 否 | 不支援 |
擴充VARCHAR長度 | 是2 | 否 | 是 | 不涉及 |
將UTF8mb3字元集修改為UTF8mb4字元集 | 否 | 否3 | 是3 | 不支援 |
刪除列預設值 | 是 | 否 | 是 | 不涉及 |
修改auto-increment值 | 是 | 否 | 是 | 不涉及 |
變更某列為NULL | 是 | 是 | 否 | 支援 |
變更某列為非NULL | 否 | 是 | 否 | 不支援 |
修改ENUM/SET列的定義 | 是 | 否 | 是4 | 不涉及 |
秒級加欄位功能僅支援將列添加至表的末尾。當表未指定主鍵時,需要將參數
implicit_primary_key的值設定為OFF,以避免在執行秒級加欄位操作時因表的最末尾的隱式主鍵列導致加列操作失敗。除此之外,不支援在壓縮表(ROW_FORMAT=COMPRESSED)、帶有全文索引的表以及暫存資料表上執行秒級加欄位操作。如果叢集不支援使用秒級加欄位功能,增加欄位將使用INPLACE方式執行DDL。此時需要進行全表重建,重建期間允許並發讀寫操作。您也可以通過並行DDL功能進行加速。此外,若您的表中存在列存索引,由於加列操作需要重建列存索引,因此,不支援對含有列存索引的表執行秒級加列操作。您可以將參數
loose_imci_enable_add_column_instant_ddl的值設定為ON來開啟秒級加列功能,此時,PolarDB會在後台非同步重建列存索引,重建期間列存索引暫不可用,詳情請參見動態增加或刪除列存索引的DDL文法。擴充VARCHAR長度時,儲存VARCHAR列長度所需的位元組數需要保持一致,才能支援快速列擴充。具體來說,對於0~255個位元組的VARCHAR列,只需要一個Byte儲存長度。而對於大於等於256位元組的VARCHAR列,就需要兩個Bytes儲存長度。只有控制VARCHAR列長度的擴充範圍,比如從0~255位元組或從256位元組擴充到更大的範圍,才能保證在執行ALTER TABLE時只修改中繼資料。即當修改VARCHAR列的長度從小於256位元組擴充到大於等於256位元組的長度時,PolarDB預設使用Copy DDL,即全程鎖表,不支援DML寫操作,僅支援讀操作。
當您不確定自己修改VARCHAR列的範圍是否滿足上述條件時,可以使用
ALGORITHM=INPLACE指定採用INPLACE演算法執行當前DDL操作。此時,如果不支援快速列擴充,則會直接報錯。樣本如下:ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256); ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.VARCHAR類型屬於變長儲存類型,磁碟僅儲存實際長度,因此建議您在使用VARCHAR類型的欄位時,考慮將最大長度直接調整到256個位元組及以上,以避免在擴充欄位時可能需要使用COPY演算法。
當參數
loose_innodb_support_instant_modify_charset的值為ON,且滿足以下條件時,將列的字元集從UTF8mb3修改至UTF8mb4僅修改中繼資料,無需修改資料。否則,需要使用COPY演算法進行表重建,且重建期間全程鎖表,目標表只能讀,不能執行寫入操作。列類型為CHAR、VARCHAR、ENUM以及TEXT類型。
修改的列上不存在任何索引。
字元集轉換前後,列的最大儲存長度均小於256或均大於255。
您可以通過指定ALGORITHM=INPLACE來強制使用非重建表的方式執行DDL,如果需要使用COPY演算法才能執行時,會立刻返回報錯。樣本如下:
ALTER TABLE test modify column b char(1) CHARACTER SET utf8mb4 default null,algorithm = inplace; ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.僅當資料類型的儲存大小不發生改變,且向ENUM或SET的末尾追加元素時,才可以僅修改中繼資料,不重建整張表。否則需要使用COPY演算法進行表重建。
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加列 | 是 | 否1 | 是1 | 支援1 |
刪除列 | 是 | 是 | 否 | 支援 |
重新命名列 | 是 | 否 | 是 | 不涉及 |
重排序列 | 是 | 是 | 否 | 支援 |
設定列的預設值 | 是 | 否 | 是 | 不涉及 |
修改列注釋 | 是 | 否 | 是 | 不涉及 |
修改列類型 | 否 | 是 | 否 | 不支援 |
擴充VARCHAR長度 | 是2 | 否 | 是 | 不涉及 |
將UTF8mb3字元集修改為UTF8mb4字元集 | 否 | 是 | 否 | 不支援 |
刪除列預設值 | 是 | 否 | 是 | 不涉及 |
修改auto-increment值 | 是 | 否 | 是 | 不涉及 |
變更某列為NULL | 是 | 是 | 否 | 支援 |
變更某列為非NULL | 否 | 是 | 否 | 不支援 |
修改ENUM/SET列的定義 | 是 | 否 | 是3 | 不涉及 |
開啟秒級加欄位功能需要將參數
loose_innodb_support_instant_add_column的值設定為ON,且僅支援將列添加至表的末尾。當表未指定主鍵時,需要將參數implicit_primary_key的值設定為OFF,以避免在執行秒級加欄位操作時因表的最末尾的隱式主鍵列導致加列操作失敗。除此之外,不支援在壓縮表(ROW_FORMAT=COMPRESSED)、帶有全文索引的表以及暫存資料表上執行秒級加欄位操作。如果叢集不支援使用秒級加欄位功能,增加欄位將使用INPLACE方式執行DDL。此時需要進行全表重建,重建期間允許並發讀寫操作。您也可以通過並行DDL功能進行加速。擴充VARCHAR長度時,儲存VARCHAR列長度所需的位元組數需要保持一致,才能支援快速列擴充。具體來說,對於0~255個位元組的VARCHAR列,只需要一個Byte儲存長度。而對於大於等於256位元組的VARCHAR列,就需要兩個Bytes儲存長度。只有控制VARCHAR列長度的擴充範圍,比如從0~255位元組或從256位元組擴充到更大的範圍,才能保證在執行ALTER TABLE時只修改中繼資料。即當修改VARCHAR列的長度從小於256位元組擴充到大於等於256位元組的長度時,PolarDB預設使用Copy DDL,即全程鎖表,不支援DML寫操作,僅支援讀操作。
當您不確定自己修改VARCHAR列的範圍是否滿足上述條件時,可以使用
ALGORITHM=INPLACE指定採用INPLACE演算法執行當前DDL操作。此時,如果不支援快速列擴充,則會直接報錯。樣本如下:ALTER TABLE table_name ALGORITHM=INPLACE, CHANGE COLUMN c1 c1 VARCHAR(256); ERROR 0A000: ALGORITHM=INPLACE is not supported. Reason: Cannot change column type INPLACE. Try ALGORITHM=COPY.VARCHAR類型屬於變長儲存類型,磁碟僅儲存實際長度,因此建議您在使用VARCHAR類型的欄位時,考慮將最大長度直接調整到256個位元組及以上,以避免在擴充欄位時可能需要使用COPY演算法。
僅當資料類型的儲存大小不發生改變,且向ENUM或SET的末尾追加元素時,才可以僅修改中繼資料,不重建整張表。否則需要使用COPY演算法進行表重建。
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加列 | 是 | 否1 | 是1 | 不支援 |
刪除列 | 是 | 是 | 否 | 不支援 |
重新命名列 | 是 | 否 | 是 | 不涉及 |
重排序列 | 是 | 是 | 否 | 不支援 |
設定列的預設值 | 是 | 否 | 是 | 不涉及 |
修改列注釋 | 是 | 否 | 是 | 不涉及 |
修改列類型 | 否 | 是 | 否 | 不支援 |
擴充VARCHAR長度 | 否 | 是 | 否 | 不支援 |
將UTF8mb3字元集修改為UTF8mb4字元集 | 否 | 是 | 否 | 不支援 |
刪除列預設值 | 是 | 否 | 是 | 不涉及 |
修改auto-increment值 | 是 | 否 | 是 | 不涉及 |
變更某列為NULL | 是 | 是 | 否 | 不支援 |
變更某列為非NULL | 否 | 是 | 否 | 不支援 |
修改ENUM/SET列的定義 | 是 | 否 | 是2 | 不涉及 |
開啟秒級加欄位功能需要將參數
loose_innodb_support_instant_add_column的值設定為ON,且僅支援將列添加至表的末尾。當表未指定主鍵時,需要將參數implicit_primary_key的值設定為OFF,以避免在執行秒級加欄位操作時因表的最末尾的隱式主鍵列導致加列操作失敗。除此之外,不支援在壓縮表(ROW_FORMAT=COMPRESSED)、帶有全文索引的表、暫存資料表以及分區表上執行秒級加欄位操作。如果叢集不支援使用秒級加欄位功能,增加欄位將使用INPLACE方式執行DDL。此時需要進行全表重建,重建期間允許並發讀寫操作。說明PolarDB MySQL版5.6版本的秒級加列功能目前處於灰階階段,如需使用,請前往配額中心,根據配額ID
polardb_mysql_iac_56找到配額名稱,在對應的操作列單擊申請來開通該功能。僅當資料類型的儲存大小不發生改變,且向ENUM或SET的末尾追加元素時,才可以僅修改中繼資料,不重建整張表。否則需要使用COPY演算法進行表重建。
Table操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
修改ROW_FORMAT | 是 | 是 | 否 | 支援 |
修改KEY_BLOCK_SIZE | 是 | 是 | 否 | 支援 |
設定持久化統計資訊 | 是 | 否 | 是 | 不涉及 |
聲明character set | 是 | 否 | 是 | 不涉及 |
轉換character set | 否 | 是 | 否 | 不支援 |
Optimize表 | 是 | 是 說明 通過 | 否 | 支援 |
重建表 | 是 | 是 | 否 | 支援 |
重新命名表 | 是 | 否 | 是 | 不涉及 |
修改表注釋 | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
修改ROW_FORMAT | 是 | 是 | 否 | 支援 |
修改KEY_BLOCK_SIZE | 是 | 是 | 否 | 支援 |
設定持久化統計資訊 | 是 | 否 | 是 | 不涉及 |
聲明character set | 是 | 否 | 是 | 不涉及 |
轉換character set | 否 | 是 | 否 | 不支援 |
Optimize表 | 是 | 是 說明 通過 | 否 | 支援 |
重建表 | 是 | 是 | 否 | 支援 |
重新命名表 | 是 | 否 | 是 | 不涉及 |
修改表注釋 | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
修改ROW_FORMAT | 是 | 是 | 否 | 支援 |
修改KEY_BLOCK_SIZE | 是 | 是 | 否 | 支援 |
設定持久化統計資訊 | 是 | 否 | 是 | 不涉及 |
聲明character set | 是 | 否 | 是 | 不涉及 |
轉換character set | 否 | 是 | 否 | 不支援 |
Optimize表 | 是 | 是 說明 通過 | 否 | 支援 |
重建表 | 是 | 是 | 否 | 支援 |
重新命名表 | 是 | 否 | 是 | 不涉及 |
修改表注釋 | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
修改ROW_FORMAT | 是 | 是 | 否 | 不支援 |
修改KEY_BLOCK_SIZE | 是 | 是 | 否 | 不支援 |
設定持久化統計資訊 | 是 | 否 | 是 | 不涉及 |
聲明character set | 是 | 否 | 是 | 不涉及 |
轉換character set | 否 | 是 | 否 | 不支援 |
Optimize表 | 是 | 是 說明 通過 | 否 | 不支援 |
重建表 | 是 | 是 | 否 | 不支援 |
重新命名表 | 是 | 否 | 是 | 不涉及 |
修改表注釋 | 是 | 否 | 是 | 不涉及 |
Generated Column操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改元資訊 | 支援並行DDL |
增加STORED Column | 否 說明 由於增加Stored Column運算式涉及SQL/Server層,因此不支援在增加Stored Column時使用Online DDL。 | 是 | 否 | 不支援 |
修改STORED Column順序 | 否 | 是 | 否 | 不支援 |
刪除STORED Column | 是 | 是 | 否 | 支援 |
增加VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
修改VIRTUAL Column順序 | 否 | 是 | 否 | 不支援 |
刪除VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加STORED Column | 否 說明 由於增加Stored Column運算式涉及SQL/Server層,因此不支援在增加Stored Column時使用Online DDL。 | 是 | 否 | 不支援 |
修改STORED Column順序 | 否 | 是 | 否 | 不支援 |
刪除STORED Column | 是 | 是 | 否 | 支援 |
增加VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
修改VIRTUAL Column順序 | 否 | 是 | 否 | 不支援 |
刪除VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加STORED Column | 否 說明 由於增加Stored Column運算式涉及SQL/Server層,因此不支援在增加Stored Column時使用Online DDL。 | 是 | 否 | 不支援 |
修改STORED Column順序 | 否 | 是 | 否 | 不支援 |
刪除STORED Column | 是 | 是 | 否 | 支援 |
增加VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
修改VIRTUAL Column順序 | 否 | 是 | 否 | 不支援 |
刪除VIRTUAL Column | 是 | 否 | 是 | 不涉及 |
PolarDB MySQL版5.6版本
PolarDB MySQL版5.6版本不支援Generated Column特性。
Foreign Key操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
刪除Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
刪除Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
刪除Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
刪除Foreign Key | 是1 | 否1 | 是1 | 不涉及 |
只有在關閉了foreign_key_checks開關,並且只修改中繼資料的情況下,才支援使用INPLACE DDL。否則只支援使用COPY DDL,且需要全程鎖表。
分區表操作
PolarDB MySQL版8.0.2版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加分區(ADD) | 是1 | 否2 | 是 | 不支援 |
刪除分區(DROP) | 是1 | 否2 | 否 | 不支援 |
刪除分區資料表空間(DISCARD) | 否 | 否 | 否 | 不支援 |
匯入分區資料表空間(IMPORT) | 否 | 否 | 否 | 不支援 |
截斷分區(TRUNCATE) | 是 | 否 | 否 | 不支援 |
合并分區(COALESCE) | 否 | 是3 | 否 | 不支援 |
重分布分區(REORGANIZE) | 是1 | 否7 | 否 | 不支援 |
交換分區(EXCHANGE) | 是1 | 否 | 是 | 不支援 |
分析分區(ANALYZE) | 是 | 否 | 否8 | 不支援 |
檢查分區(CHECK) | 是 | 否 | 否9 | 不支援 |
最佳化分區(OPTIMIZE) | 是4 | 是4 | 否 | 支援4 |
重建分區(REBUILD) | 是1 | 否7 | 否 | 不支援 |
修複分區(REPAIR) | 是 | 否10 | 否 | 不支援 |
錶轉分區 | 否 | 是 | 是5 | 不支援 |
分區轉表 | 否 | 是 | 否 | 不支援 |
建立PARTIAL INDEX | 是 | 否6 | 否 | 支援 |
引入分區級中繼資料鎖MDL,將參數
loose_partition_level_mdl_enabled的值設為true後,執行DDL操作時不影響不涉及的分區上的DML,詳細資料請查看線上分區維護。RANGE和LIST分區增加或刪除分區時不需要重建表。HASH和KEY分區增加分區時需要重建表,HASH和KEY分區不支援刪除分區操作。
僅支援HASH和KEY分區。
對InnoDB引擎中的表執行OPTIMIZE PARTITION操作時,會重建整張分區表。重建期間支援對目標表的讀寫操作。此時,您可以將參數
innodb_parallel_build_primary_index的值設定為ON,使用並行DDL功能加快重建速度。秒級轉換僅支援將普通錶快速轉換為RANGE分區表。
PolarDB MySQL版支援建立和刪除分區粒度的索引,詳情請參見部分索引(Partial Index)。
重分布分區或重建分區只重建指定需要做資料重分布和重建的分區,其他分區不受影響。
分析分區只修改統計資訊,不修改表的中繼資料和資料。
檢查分區不修改中繼資料和資料。
修複分區只重建指定需要修複的分區。
PolarDB MySQL版8.0.1版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加分區(ADD) | 否 | 否1 | 是 | 不支援 |
刪除分區(DROP) | 否 | 否2 | 否 | 不支援 |
刪除分區資料表空間(DISCARD) | 否 | 否 | 否 | 不支援 |
匯入分區資料表空間(IMPORT) | 否 | 否 | 否 | 不支援 |
截斷分區(TRUNCATE) | 是 | 否 | 否 | 不支援 |
合并分區(COALESCE) | 否 | 是 | 否 | 不支援 |
重分布分區(REORGNIZATE) | 否 | 否4 | 否 | 不支援 |
交換分區(EXCHANGE) | 是 | 是 | 是 | 不支援 |
分析分區(ANALYZE) | 是 | 是 | 否5 | 不支援 |
檢查分區(CHECK) | 是 | 否 | 否6 | 不支援 |
最佳化分區(OPTIMIZE) | 是3 | 是3 | 否 | 支援3 |
重建分區(REBUILD) | 否 | 否4 | 否 | 不支援 |
修複分區(REPAIR) | 是 | 否4 | 否 | 不支援 |
錶轉分區 | 否 | 是 | 否 | 不支援 |
分區轉表 | 否 | 是 | 否 | 不支援 |
RANGE和LIST分區增加分區時不需要重建表。HASH和KEY分區增加分區時需要重建表。
HASH和KEY分區不支援刪除分區操作。
對InnoDB引擎中的表執行OPTIMIZE PARTITION操作時,會重建整張分區表。重建期間支援對目標表的讀寫操作。此時,您可以將參數
innodb_parallel_build_primary_index的值設定為ON,使用並行DDL功能加快重建速度。重分布、重建和修複分區只重建指定需要重分布、重建和修複的分區, 不涉及其他分區。
分析分區只修改統計資訊,不修改表的中繼資料和資料。
檢查分區不修改中繼資料和資料。
PolarDB MySQL版5.7版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加分區(ADD) | 否 | 否1 | 是 | 不支援 |
刪除分區(DROP) | 否 | 否1 | 否 | 不支援 |
刪除分區資料表空間(DISCARD) | 否 | 否 | 否 | 不支援 |
匯入分區資料表空間(IMPORT) | 否 | 否 | 否 | 不支援 |
截斷分區(TRUNCATE) | 是 | 否 | 否 | 不支援 |
合并分區(COALESCE) | 否 | 是 | 否 | 不支援 |
重分布分區(REORGNIZATE) | 否 | 否2 | 否 | 不支援 |
交換分區(EXCHANGE) | 是 | 否 | 是 | 不支援 |
分析分區(ANALYZE) | 是 | 否 | 否3 | 不支援 |
檢查分區(CHECK) | 是 | 否 | 否4 | 不支援 |
最佳化分區(OPTIMIZE) | 否 | 是 | 否 | 不支援 |
重建分區(REBUILD) | 否 | 否2 | 否 | 不支援 |
修複分區(REPAIR) | 是 | 否2 | 否 | 不支援 |
錶轉分區 | 否 | 是 | 否 | 不支援 |
分區轉表 | 否 | 是 | 否 | 不支援 |
RANGE和LIST分區增加或刪除分區時不需要重建表。HASH和KEY分區增加分區時需要重建表,HASH和KEY分區不支援刪除分區操作。
重分布、重建和修複分區只重建指定需要重分布、重建和修複的分區, 不涉及其他分區。
分析分區只修改統計資訊,不修改表的中繼資料和資料。
檢查分區不修改中繼資料和資料。
PolarDB MySQL版5.6版本
操作 | 允許並發DML | 重建表 | 僅修改中繼資料 | 支援並行DDL |
增加分區(ADD) | 否 | 否1 | 是 | 不支援 |
刪除分區(DROP) | 否 | 否1 | 否 | 不支援 |
刪除分區資料表空間(DISCARD) | 否 | 否 | 否 | 不支援 |
匯入分區資料表空間(IMPORT) | 否 | 否 | 否 | 不支援 |
截斷分區(TRUNCATE) | 是 | 否 | 否 | 不支援 |
合并分區(COALESCE) | 否 | 是 | 否 | 不支援 |
重分布分區(REORGNIZATE) | 否 | 否2 | 否 | 不支援 |
交換分區(EXCHANGE) | 是 | 否 | 是 | 不支援 |
分析分區(ANALYZE) | 是 | 否 | 否3 | 不支援 |
檢查分區(CHECK) | 是 | 否 | 否4 | 不支援 |
最佳化分區(OPTIMIZE) | 否 | 是 | 否 | 不支援 |
重建分區(REBUILD) | 否 | 否2 | 否 | 不支援 |
修複分區(REPAIR) | 是 | 否2 | 否 | 不支援 |
錶轉分區 | 否 | 是 | 否 | 不支援 |
分區轉表 | 否 | 是 | 否 | 不支援 |
RANGE和LIST分區增加或刪除分區時不需要重建表。HASH和KEY分區增加分區時需要重建表,HASH和KEY分區不支援刪除分區操作。
重分布、重建和修複分區只重建指定需要重分布、重建和修複的分區, 不涉及其他分區。
分析分區只修改統計資訊,不修改表的中繼資料和資料。
檢查分區不修改中繼資料和資料。
DDL執行方式
當PolarDB MySQL版採用INPLACE或INSTANT演算法執行DDL操作時,建議優先使用核心方式(Online DDL)執行。該方式執行速度快,穩定性高。
當PolarDB MySQL版採用COPY演算法執行DDL操作時,DDL需要全程鎖表,在執行期間無法對目標表進行讀寫操作。此時可以考慮使用DMS無鎖變更或gh-ost等第三方工具執行DDL。此類第三方工具可以在DDL執行期間允許讀寫操作,但通常情況下此類工具的執行速度較慢,在大表或高並發情境下,若增量資料過多,容易執行失敗。
使用核心方式和第三方工具執行DDL操作的差異請參見下表:
執行方式 | 允許並發讀寫 | 執行速率 | 是否需要開啟Binlog | 並行加速 |
核心(Online DDL) | 是 | 快 | 否 | 支援 |
第三方工具(DMS無鎖變更、gh-ost等) | 是 | 慢 | 是 | 不支援 |
聯絡我們
若您對DDL操作有任何疑問,請聯絡我們。