主頁(yè) > 知識(shí)庫(kù) > MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理

MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理

熱門標(biāo)簽:400電話申請(qǐng)廠家現(xiàn)貨 百度地圖標(biāo)注要什么軟件 天津公司外呼系統(tǒng)軟件 中國(guó)地圖標(biāo)注公司 電話機(jī)器人的價(jià)格多少錢一個(gè)月 昌德訊外呼系統(tǒng) 福建外呼電銷機(jī)器人加盟 徐涇鎮(zhèn)騰訊地圖標(biāo)注 自己做地圖標(biāo)注需要些什么

1. DDL原子性概述

8.0之前并沒(méi)有統(tǒng)一的數(shù)據(jù)字典dd,server層和引擎層各有一套元數(shù)據(jù),sever層的元數(shù)據(jù)包括(.frm,.opt,.par,.trg等),用于存儲(chǔ)表定義,分區(qū)表定義,觸發(fā)器定義等信息;innodb層也有自己一套元數(shù)據(jù),包括表信息,索引信息等,這兩套元數(shù)據(jù)并沒(méi)有機(jī)制保證一致性,這就導(dǎo)致了在異常情況下可能存在元數(shù)據(jù)不一致問(wèn)題,一種典型場(chǎng)景下,刪表操作,sever層的frm已經(jīng)成功刪除了,但引擎層數(shù)據(jù)字典并沒(méi)有更新,導(dǎo)致再建重名表失敗的問(wèn)題。同樣的,比如drop table t1,t2;可能出現(xiàn)只刪除了t1,而t2仍然存在等問(wèn)題。

8.0的一個(gè)重要工作是將數(shù)據(jù)字典統(tǒng)一,獨(dú)立了DD(數(shù)據(jù)字典)模塊,廢棄了server層的元數(shù)據(jù),將innodb的元數(shù)據(jù)抽象出一條DD接口供server層和innnodb層公用。在DD的基礎(chǔ)上,引入了DDL的原子性特性,確保DDL操作要么全做,要么全不做的能力。實(shí)現(xiàn)這一套邏輯的關(guān)鍵點(diǎn)在于將ddl涉及到的修改,包括dd數(shù)據(jù)字典修改,引擎層的修改(創(chuàng)建文件,初始化tablespace,創(chuàng)建btree等)和寫binlog作為一個(gè)“事務(wù)”,利用事務(wù)的原子性特點(diǎn)來(lái)保證ddl操作的原子性。

2.DDL原子性實(shí)現(xiàn)原理

實(shí)現(xiàn)原子性的關(guān)鍵在于確保dd數(shù)據(jù)字典修改,引擎層的修改和寫binlog是一個(gè)事務(wù)。MySQL已有的XA事務(wù)機(jī)制能有效保證DML事務(wù)和binlog的一致性。而ddl數(shù)據(jù)字典也是通過(guò)innodb引擎存儲(chǔ),因此做到dd數(shù)據(jù)字典修改和binlog一致是容易的;那么還需要解決的一個(gè)問(wèn)題是,dd數(shù)據(jù)字典和引擎層修改的一致性,引擎層的修改并不都是記redo的,比如創(chuàng)建文件,rename文件名,或者清理cache等,無(wú)法簡(jiǎn)單地通過(guò)XA機(jī)制解決問(wèn)題,因此8.0還引入了一套DDL_LOG機(jī)制。具體而言,就是將不記redo的一些操作,通過(guò)記日志的方式寫入到ddl_log表中,而這個(gè)表是innodb引擎表,通過(guò)保證ddl_log數(shù)據(jù)與dd數(shù)據(jù)字典修改達(dá)成一致,而最終解決dd數(shù)據(jù)字典修改,引擎層的修改和寫binlog一致性問(wèn)題。

3.DD引入前后對(duì)比

 

 

4.DDL操作實(shí)現(xiàn)邏輯

引入ddl_log表后,ddl操作在原有的基礎(chǔ)上有一些變化,主要有兩點(diǎn),一點(diǎn)是在執(zhí)行ddl的過(guò)程中,會(huì)記錄ddl操作到ddl_log表中;另一點(diǎn)是新增了一個(gè)post_ddl階段,ddl事務(wù)提交后,做一些ddl的收尾動(dòng)作,比如drop-table,真正的刪除物理文件是在post-ddl階段做的。post-ddl做的事情主要就是,讀取ddl-log內(nèi)容,進(jìn)行回放執(zhí)行。ddl操作類型如下:

enum class Log_Type : uint32_t {
/** Smallest log type */
SMALLEST_LOG = 1,
/** Drop an index tree */
FREE_TREE_LOG = 1,
/** Delete a file */
DELETE_SPACE_LOG,
/** Rename a file */
RENAME_SPACE_LOG,
/** Drop the entry in innodb_dynamic_metadata */
DROP_LOG,
/** Rename table in dict cache. */
RENAME_TABLE_LOG,
/** Remove a table from dict cache */
REMOVE_CACHE_LOG,
/** Alter Encrypt a tablespace */
ALTER_ENCRYPT_TABLESPACE_LOG,
/** Biggest log type */
BIGGEST_LOG = ALTER_ENCRYPT_TABLESPACE_LOG
};

通過(guò)innodb_print_ddl_logs開關(guān),可以看到ddl過(guò)程中寫入到innodb_ddl_log表中的內(nèi)容。下面會(huì)以幾個(gè)典型的ddl操作產(chǎn)生的ddl_log來(lái)說(shuō)明如何保證ddl的原子性。

4.1 create table

語(yǔ)句:create table dd_tt(id int primary key, c1 int); 

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=352, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log delete : 352
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=353, thread_id=23, table_id=1128, new_file_path=mysql/dd_tt]
[InnoDB] DDL log delete : 353
[InnoDB] DDL log insert : [DDL record: FREE, id=354, thread_id=23, space_id=71, index_id=231, page_no=4]
[InnoDB] DDL log delete : 354
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23 

說(shuō)明:

1.所有insert操作都是一個(gè)單獨(dú)的事務(wù),對(duì)應(yīng)的逆向delete操作是整個(gè)ddl事務(wù)的一部分。

2.insert操作記錄的是文件操作的逆向操作,比如建table_space,逆向操作就是delete_space_log。

3.如果ddl事務(wù)最終成功,那么所有逆向delete操作也最終生效,ddl_log日志被正常清理;如果ddl事務(wù)執(zhí)行過(guò)程中失敗(比如實(shí)例crash),那么delete操作回滾,ddl_log表中殘留3條insert_log,recover時(shí),replay這些ddl_log,即可以清理ddl過(guò)程中產(chǎn)生的垃圾。

4.crash-recovery時(shí),若binlog已經(jīng)落盤,則對(duì)應(yīng)的ddl事務(wù)處于prepare狀態(tài),那么最終事務(wù)要提交,ddl_log被清理干凈;若binlog沒(méi)有落盤,則ddl事務(wù)需要回滾,ddl_log表中殘留3條記錄,在故障恢復(fù)結(jié)束后,需要replay這些記錄,實(shí)際上就是建文件,創(chuàng)建btree等逆向操作,確?;貪L后是干凈的。

4.2 drop table

語(yǔ)句:drop table dd_tt;

[InnoDB] DDL log insert : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=356, thread_id=23, space_id=71, old_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log replay : [DDL record: DROP, id=355, thread_id=23, table_id=1128]
[InnoDB] DDL log post ddl : end for thread id : 23

說(shuō)明:對(duì)于drop操作而言,執(zhí)行過(guò)程中只是操作ddl_log,并不做真正的drop物理表操作。在post-ddl階段,會(huì)讀取ddl_log表中的記錄并replay,做真正的刪除動(dòng)作。如果執(zhí)行過(guò)程中crash了,那么整個(gè)ddl事務(wù)會(huì)回滾,這其中也包含ddl_log中的內(nèi)容也會(huì)回滾,那么整個(gè)drop操作就相當(dāng)于沒(méi)發(fā)生一樣。

4.3  add index

語(yǔ)句:alter table dd_tt add index idx_c1(c1);

[InnoDB] DDL log insert : [DDL record: FREE, id=360, thread_id=23, space_id=72, index_id=233, page_no=5]   
[InnoDB] DDL log delete : 360
[InnoDB] DDL log post ddl : begin for thread id : 23                
[InnoDB] DDL log post ddl : end for thread id : 23

說(shuō)明: 建索引與建表類似,insert操作部分是一個(gè)事務(wù),單獨(dú)提交,配套會(huì)記錄一個(gè)delete操作,這個(gè)操作是整個(gè)ddl事務(wù)的一部分,事務(wù)如果最終提交,那么ddl-log內(nèi)容被刪除;如果事務(wù)最終回滾,那么ddl-log中會(huì)殘留一條FREE-log,通過(guò)replay則可以清理建好的索引,達(dá)到回滾的效果。 

4.4  drop index

語(yǔ)句:alter table dd_tt drop index idx_c1;

[InnoDB] DDL log insert : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log replay : [DDL record: FREE, id=361, thread_id=23, space_id=72, index_id=233, page_no=5]
[InnoDB] DDL log post ddl : end for thread id : 23 

說(shuō)明:

與drop table類似,執(zhí)行過(guò)程中只記錄日志,在post-ddl階段才進(jìn)行真正的刪除操作。

4.5 add column

語(yǔ)句:alter table dd_tt add column c2 int;

[InnoDB] DDL log post ddl : begin for thread id : 23
[InnoDB] DDL log post ddl : end for thread id : 23

說(shuō)明:

8.0加列是instant-ddl,只修改元數(shù)據(jù),與dml事務(wù)類似,不依賴ddl-log保證原子性。

4.6 drop column

語(yǔ)句:alter table dd_tt drop column c2;

語(yǔ)句分解:

1.prepare階段:

create table #sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=362, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1129-2815969725.ibd] 
[InnoDB] DDL log delete : 362
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=363, thread_id=23, table_id=1130, new_file_path=mysql/#sql-ib1129-2815969725]  
[InnoDB] DDL log delete : 363
[InnoDB] DDL log insert : [DDL record: FREE, id=364, thread_id=23, space_id=73, index_id=234, page_no=4]         
[InnoDB] DDL log delete : 364

2.peform階段:nothing about ddl-log

3.commit階段:

3.1 alter table dd_tt rename to #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: DROP, id=365, thread_id=23, table_id=1129]     br>[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=366, thread_id=23, space_id=72, old_file_path=./mysql/#sql-ib1130-2815969726.ibd, new_file_path=./mysql/dd_tt.ibd]
[InnoDB] DDL log delete : 366
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=367, thread_id=23, table_id=1129, old_file_path=mysql/#sql-ib1130-2815969726, new_file_path=mysql/dd_tt]
[InnoDB] DDL log delete : 367

逆向操作:alter table mysql/#sql-ib1130-2815969726 rename to dd_tt;

3.2 alter table #sql-ib1129-2815969725 rename to dd_tt;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

逆向操作:alter table dd_tt rename to mysql/#sql-ib1129-2815969725;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

僅僅記錄操作,在post-ddl階段才做清理。                                                              

post-ddl階段:

drop table #sql-ib1130-2815969726;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=368, thread_id=23, space_id=73, old_file_path=./mysql/dd_tt.ibd, new_file_path=./mysql/#sql-ib1129-2815969725.ibd]
[InnoDB] DDL log delete : 368
[InnoDB] DDL log insert : [DDL record: RENAME TABLE, id=369, thread_id=23, table_id=1130, old_file_path=mysql/dd_tt, new_file_path=mysql/#sql-ib1129-2815969725]
[InnoDB] DDL log delete : 369

說(shuō)明:drop column是copy類型的ddl,基本邏輯是新建一張臨時(shí)表,拷貝數(shù)據(jù),最后再進(jìn)行一次rename操作。主要包括4個(gè)階段:

1.prepare階段:建臨時(shí)表的過(guò)程與建表過(guò)程的ddl-log操作類似,insert-log作為單獨(dú)事務(wù)直接提交,delete-log是整個(gè)事務(wù)的一部分。

這個(gè)階段如果出現(xiàn)異常,ddl-log表中殘留了逆操作記錄,crash-recovery時(shí),可以在replay實(shí)現(xiàn)清理。

2.peform階段: 拷貝數(shù)據(jù)結(jié)束,實(shí)現(xiàn)online-ddl邏輯。

3.拷貝數(shù)據(jù)結(jié)束后,需要進(jìn)行rename交換表名操作。

   1)DROP,刪除臨時(shí)表

   2)RENAME SPACE/TABLE 將./mysql/#sql-ib1130-2815969726.ibd 重命名為dd_tt.idb

   3)REANAME SPACE/TABLE 將dd_tt.idb重名為/#sql-ib1129-2815969725.idb

   4)記錄刪除舊表sql-ib1130-2815969726.ibd操作,post-ddl階段做真正的刪除。

如果這個(gè)階段出現(xiàn)異常,同樣的insert-log單獨(dú)一個(gè)事務(wù),delete作為整個(gè)事務(wù)的一部分,insert-log會(huì)殘留在ddl-log表中,通過(guò)replay可以做清理,還原dd_tt的數(shù)據(jù),并清理臨時(shí)表#sql-ib1130-2815969726.ibd。

4.post-ddl階段:

  1).物理刪除舊文件./mysql/#sql-ib1130-2815969726.ibd

  2).清理mysql.innodb_dynamic_metadata中相關(guān)信息。

需要注意的是,由于ddl-log表存放的內(nèi)容實(shí)際上逆向操作,所以搜集ddl-log時(shí),實(shí)際上是逆序搜集回放的。

4.7 truncate table

語(yǔ)句:truncate table  dd_tt;

語(yǔ)句分解:

1.rename dd_tt to #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: RENAME SPACE, id=372, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd, new_file_path=./mysql/dd_tt.ibd
[InnoDB] DDL log delete : 372

2.drop table #sql-ib1130-2815969727;

[InnoDB] DDL log insert : [DDL record: DROP, id=373, thread_id=23, table_id=1130]     
[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd]

3.create table dd_tt;

[InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=375, thread_id=23, space_id=74, old_file_path=./mysql/dd_tt.ibd]     
[InnoDB] DDL log delete : 375
[InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=376, thread_id=23, table_id=1131, new_file_path=mysql/dd_tt]      
[InnoDB] DDL log delete : 376
[InnoDB] DDL log insert : [DDL record: FREE, id=377, thread_id=23, space_id=74, index_id=235, page_no=4]         
[InnoDB] DDL log delete : 377
[InnoDB] DDL log post ddl : begin for thread id : 23                      
[InnoDB] DDL log replay : [DDL record: DELETE SPACE, id=374, thread_id=23, space_id=73, old_file_path=./mysql/#sql-ib1130-2815969727.ibd] 
[InnoDB] DDL log replay : [DDL record: DROP, id=373, thread_id=23, table_id=1130]    

[InnoDB] DDL log post ddl : end for thread id : 23

說(shuō)明:

1.將dd_tt重命名為sql-ib1130-2815969727

2.標(biāo)記sql-ib1130-2815969727表刪除,post-ddl階段才真正刪除

3.新建表dd_tt,同樣的insert操作是作為單獨(dú)事務(wù)提交,delete操作是整個(gè)事務(wù)的一部分,如果回滾,最終殘留了insert操作,通過(guò)replay動(dòng)作清理。 

5.DDL操作代碼堆棧

5.1 create-table

Sql_cmd_create_table::execute
-->mysql_create_table
 -->mysql_create_table_no_lock
  -->create_table_impl
  -->rea_create_base_table
   -->ha_create_table
    -->ha_create
     -->ha_innobase::create
     -->innobase_basic_ddl::create_impl
      -->create_table_info_t::create_table
      {
       ......
      }
 -->trans_commit_implicit
  -->ha_commit_trans
  -->MYSQL_BIN_LOG::prepare
   -->ha_prepare_low //所有事務(wù)引擎prepare
    {
    binlog_prepare
    innobase_xa_prepare
    }
  -->MYSQL_BIN_LOG::commit
   -->MYSQL_BIN_LOG::ordered_commit
    -->MYSQL_BIN_LOG::process_flush_stage_queue
     -->MYSQL_BIN_LOG::flush_thread_caches
     -->binlog_cache_mngr::flush
      -->binlog_cache_data::flush
       -->MYSQL_BIN_LOG::write_gtid
        -->Log_event::write
        -->MYSQL_BIN_LOG::Binlog_ofile::write //寫binlog-gtid
       -->MYSQL_BIN_LOG::write_cache
        --> MYSQL_BIN_LOG::do_write_cache
         -->Binlog_cache_storage::copy_to
         -->stream_copy
          -->Binlog_event_writer::write
           -->MYSQL_BIN_LOG::Binlog_ofile::write //寫binlog-ddl語(yǔ)句
    -->MYSQL_BIN_LOG::sync_binlog_file
    -->MYSQL_BIN_LOG::process_commit_stage_queue
     -->ha_commit_low
     {
      binlog_commit
      innobase_commit
      -->trx_commit_for_mysql
       -->trx_commit
        -->trx_commit_low
         -->trx_commit_in_memory
         -->trx_undo_insert_cleanup
     }
 -->innobase_post_ddl(ht->post_ddl(thd))
  -->Log_DDL::post_ddl
  -->replay_by_thread_id


-->create_table_info_t::create_table
 -->create_table_def
  -->dict_mem_table_create //構(gòu)造innodb內(nèi)存是字典內(nèi)存對(duì)象
  -->row_create_table_for_mysql
  -->dict_build_table_def
   -->dict_build_tablespace_for_table
    -->新建xxx.idb文件
    -->Log_DDL::write_delete_space_log
    {
     -->Log_DDL::insert_delete_space_log
     -->trx_start_internal //內(nèi)部開啟事務(wù),單獨(dú)提交。
     -->構(gòu)造DDL_Record(DELETE_SPACE_LOG)
     -->DDL_Log_Table::insert(寫入物理B-Tree)
     -->Log_DDL:delete_by_id //刪除ddl_log操作,作為ddl事務(wù)的一部分。
    }
    -->fil_ibd_create
    -->初始化segment,extent,page
  -->Log_DDL::write_remove_cache_log
  -->Log_DDL::insert_remove_cache_log
  -->Log_DDL::delete_by_id
 -->create_index(主表,二級(jí)索引)
  -->dict_create_index_tree_in_mem
  -->btr_create
  -->Log_DDL::write_free_tree_log
   -->Log_DDL::insert_free_tree_log
   -->Log_DDL:delete_by_idbr>
crash-recovery
 -->ha_post_recover
  -->post_recover_handlerton
    -->innobase_post_recover
     -->Log_DDL::recover
      -->Log_DDL::replay_all
       -->Log_DDL::replay
        {
         replay_delete_space_log
         replay_remove_cache_log
         replay_free_tree_log
         ......
        }
       -->delete_by_ids
        -->DDL_Log_Table::remove

5.2 drop table

mysql_rm_table
 -->mysql_rm_table_no_locks
  -->drop_base_table
   -->ha_delete_table
    -—>handler::ha_delete_table
     -->ha_innobase::delete_table
     -->innobase_basic_ddl::delete_impl
      -->row_drop_table_for_mysql
       -->Log_DDL::write_drop_log  // 記錄刪innodb_dynamic_metadata日志
       -—>Log_DDL::write_delete_space_log  // 記錄刪ibd日志
   -->dd::drop_table
    -->dd::cache::Dictionary_client::dropdd::Table>
     -->dd::cache::Storage_adapter::dropdd::Table>
      -->dd::sdi::drop
  -->innobase_post_ddl
   -->Log_DDL::post_ddl
    -->Log_DDL::replay_by_thread_id
     -->Log_DDL::replay
      —>Log_DDL::replay_delete_space_log // post-ddl 真正刪除innodb_dynamic_metadata
      —>Log_DDL::replay_drop_log   // post-ddl 真正刪除ibd
     -->delete_by_ids
      -->DDL_Log_Table::remove

drop table時(shí),只記錄刪除動(dòng)作日志,這些日志作為事務(wù)的整體的一部分,如果最終事務(wù)提交,那么post_ddl階段會(huì)讀取日志真正刪除;如果事務(wù)回滾,那么ddl_log也會(huì)作為事務(wù)的一部分而回滾。

參考文檔

https://dev.mysql.com/worklog/task/?id=9045

https://dev.mysql.com/worklog/task/?id=9173

https://dev.mysql.com/worklog/task/?id=9175

https://dev.mysql.com/worklog/task/?id=9525

https://dev.mysql.com/worklog/task/?id=9536

總結(jié)

以上所述是小編給大家介紹的MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理,希望對(duì)大家有所幫助,如果大家有任何疑問(wèn)請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持!
如果你覺(jué)得本文對(duì)你有幫助,歡迎轉(zhuǎn)載,煩請(qǐng)注明出處,謝謝!

您可能感興趣的文章:
  • MySQL8.0 如何快速加列
  • Mysql Online DDL的使用詳解
  • MySQL DDL 引發(fā)的同步延遲該如何解決
  • 詳解MySQL8.0原子DDL語(yǔ)法
  • MySQL在線DDL工具 gh-ost的原理解析
  • MySQL ddl語(yǔ)句的使用
  • Mysql DDL常見操作匯總
  • 解析MySQL8.0新特性——事務(wù)性數(shù)據(jù)字典與原子DDL
  • MySQL數(shù)據(jù)定義語(yǔ)言DDL的基礎(chǔ)語(yǔ)句
  • MySQL在線DDL gh-ost使用總結(jié)
  • 解決MySQL 5.7中定位DDL被阻塞的問(wèn)題
  • MySQL8.0新特性之支持原子DDL語(yǔ)句
  • MySQL曝中間人攻擊Riddle漏洞可致用戶名密碼泄露的處理方法
  • MySQL 8.0 Online DDL快速加列的相關(guān)總結(jié)

標(biāo)簽:梅河口 陜西 北京 昌都 鄂爾多斯 荊門 黔西 駐馬店

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理》,本文關(guān)鍵詞  MySQL8.0,DDL,原子,性,特性,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理》相關(guān)的同類信息!
  • 本頁(yè)收集關(guān)于MySQL8.0 DDL原子性特性及實(shí)現(xiàn)原理的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章