MySql 在修改表結(jié)構(gòu)的時(shí)候可能會(huì)中斷產(chǎn)品的正常運(yùn)行影響用戶體驗(yàn)，甚至更壞的結(jié)果，丟失數(shù)據(jù)。不是所有的數(shù)據(jù)庫(kù)管理員、程序員、系統(tǒng)管理員都非常了解Mysql能避免這種情況。DBA會(huì)經(jīng)常碰到這種生產(chǎn)中斷的情況，當(dāng)升級(jí)腳本修改了應(yīng)用層和數(shù)據(jù)庫(kù)層，或者缺乏經(jīng)驗(yàn)的管理員、開發(fā)在不是很了解Mysql內(nèi)部工作機(jī)制的情況下修改了規(guī)范文件。

真相是：

• 直接修改表結(jié)構(gòu)的過程中會(huì)鎖表（在5.6版本之前）
• 在線的數(shù)據(jù)定義語言在5.6版本不總是在線的而且也會(huì)鎖表
• 就算使用Percona工具包（在線修改定義文件）也會(huì)有若干個(gè)步驟會(huì)鎖表

Percona MySQL  服務(wù)器開發(fā)團(tuán)隊(duì)鼓勵(lì)用戶在計(jì)劃或者執(zhí)行數(shù)據(jù)庫(kù)遷移的時(shí)候先和我們溝通。我們的目標(biāo)是基于用戶給出的各種情況給出最佳的方案。旨在避免鎖表當(dāng)用戶對(duì)非常大的表執(zhí)行DDL，以確保應(yīng)用能像平常一樣正常運(yùn)行，同時(shí)也在努力改善響應(yīng)時(shí)間或增加系統(tǒng)功能。最差的情況是確保那些經(jīng)不起當(dāng)機(jī)的系統(tǒng)在黃金交易時(shí)間正常運(yùn)行。

我們使用的大多數(shù)安裝包仍然小于Mysql5.6，這需要我們不停嘗試新的安裝環(huán)境來把數(shù)據(jù)庫(kù)遷移造成的損失降到最低。這可能需要一個(gè)能“在線修改規(guī)范定義文件”的工具來升級(jí)或者修改規(guī)范文件。Mysql5.6解決這一問題的做法是通過減少重建表和鎖表的場(chǎng)景，但這個(gè)方法不能覆蓋所有的可能的操作，例如當(dāng)修改一列的數(shù)據(jù)類型時(shí)必然需要全表重構(gòu)。Przemys?aw和 Malkowski在去年盡可能詳盡的討論了Mysql5.6運(yùn)行中修改定義。

•     隨著 MySQL 5.7的新功能, 我們尋求不會(huì)鎖表的DDL操作 例如; 表優(yōu)化 和 索引重命名. (More info)

對(duì)于Mysql5.6的用戶，最好的建議是回顧一下數(shù)矩陣來熟悉在MYSQL之外執(zhí)行定義的更改，好消息是我們很擅長(zhǎng)解決這一問題。

說實(shí)話，鎖表操作會(huì)經(jīng)常被忽視，在操作30M大小的表時(shí)我們更傾向于直接修改，但是30G，300G的表就要考慮一下了。當(dāng)使用率不高或者對(duì)鎖定時(shí)間要求不是很高的的系統(tǒng)來說直接操作也許更好。可是，我們常常會(huì)遇到一個(gè)需要立即執(zhí)行的SQL，或者因?yàn)樾阅軉栴}需要緊急增加一個(gè)索引來減少加載時(shí)間。

是否需要在系統(tǒng)在線期修改表定義

上面提到，在線修改表定義是工作流中的一個(gè)模塊。通常是不錯(cuò)的解決方案，但也會(huì)遇到不能使用的場(chǎng)合，例如：當(dāng)某個(gè)表使用了觸發(fā)器。了解pt-osc在我們項(xiàng)目中的工作過程很重要，讓我們來看一下源代碼：
 

 我把上面第三步到第五步高亮出來，這是鎖表可能引起系統(tǒng)停機(jī)的時(shí)間。但步驟六設(shè)計(jì)外鍵更新是一個(gè)循環(huán)的操作，是避免在更新關(guān)系的時(shí)候隱含地重建表。有很多方法可以確保表的完整性約束，在pt-osc的說明文檔中詳細(xì)說明了，在開始之前預(yù)覽你的表結(jié)構(gòu)包括約束，并知道怎樣把修改表定義所造成的影響降到最低。

最近，我們通知了一個(gè)擁有高并發(fā)高事務(wù)量系統(tǒng)的用戶運(yùn)行pt-osc在大型數(shù)據(jù)表上。這件事對(duì)于他們來說很平常，幾小時(shí)后我們的客服被告知該客戶遇到了最大連接數(shù)超過的問題。這個(gè)問題是如何產(chǎn)生的呢？當(dāng)pt-osc運(yùn)行到步驟五的時(shí)候會(huì)嘗試去鎖定數(shù)據(jù)并重命名原表和隱藏表，然而這不會(huì)在開啟事務(wù)的時(shí)候立即執(zhí)行，因此這條線程會(huì)被排在重命名后面。這表現(xiàn)在用戶應(yīng)用上就是系統(tǒng)停機(jī)。數(shù)據(jù)庫(kù)無法開啟新的連接并且所有的線程都被阻塞在重命名命令之后。

    5.5.3版本的說明，當(dāng)開啟一個(gè)事務(wù)時(shí)會(huì)鎖定它會(huì)用到的所有表的數(shù)據(jù)（不依賴于存儲(chǔ)引擎），并在事務(wù)提交的時(shí)候釋放鎖。這樣做確保了在開啟事務(wù)期間不能修改表的定義。

長(zhǎng)遠(yuǎn)來看我們可以采用一些新的技術(shù)來避免這種情況，例如non-default pt-osc的選項(xiàng)，換言之就是不會(huì)刪除原表把數(shù)據(jù)換到新表。這種聯(lián)合脫離了隱藏表和觸發(fā)器，我們應(yīng)該鼓勵(lì)將重命名操作變得原子化。

校訂：2.2版本的percona工具新增了一個(gè)變量