整理這篇文章的緣由：

互聯(lián)網(wǎng)應(yīng)用會頻繁加功能，修改需求。那么表結(jié)構(gòu)也會經(jīng)常修改，加字段，加索引。在線直接在生產(chǎn)環(huán)境的表中修改表結(jié)構(gòu),對用戶使用網(wǎng)站是有影響。

以前我一直為這個問題頭痛。當(dāng)然那個時候不需要我來考慮,雖然我們沒專門的dba，他們數(shù)據(jù)量比我們更大，那這種問題也會存在。所以我很想看看業(yè)界是怎么做的,我想尋找有沒有更高級的方案，呵呵，讓我覺得每次開發(fā)一個新功能，我在線加字段都比較糾結(jié)。后來只知道，不清楚在什么時候，無意中看到一個資料介紹online-schema-change這個工具，于是順便搜出了不少東西。后來逐漸發(fā)現(xiàn)騰訊，淘寶他們都會存在這種問題，我發(fā)現(xiàn)解決思路都差不多。具體看完我這篇歸納的文章

?

?

?

由于mysql在線ddl(加字段、加索引等修改表結(jié)構(gòu)之類的操作）過程如下：

?A.對表加鎖(表此時只讀)
B.復(fù)制原表物理結(jié)構(gòu)
C.修改表的物理結(jié)構(gòu)
D.把原表數(shù)據(jù)導(dǎo)入中間表中，數(shù)據(jù)同步完后，鎖定中間表，并刪除原表
E.rename中間表為原表
F.刷新數(shù)據(jù)字典，并釋放鎖

?

?

在這個過程中會鎖表。造成當(dāng)前操作的表無法寫入數(shù)據(jù)，影響用戶使用。由于需要復(fù)制原表的數(shù)據(jù)到中間表，所以表的數(shù)據(jù)量越大，等待的時候越長，卡死在那里(用戶被拒絕執(zhí)行update和insert操作,表現(xiàn)就是延遲了一直在等待)。

其實就是對表加了個排它鎖，這個時候其他用戶只能讀表的數(shù)據(jù),不能寫。想具體體驗一下是什么效果，我以前測驗對mysql的表加鎖，操作的時候是如何的：http://www.cnblogs.com/wangtao_20/p/3463435.html

?

平時進(jìn)行修改表的結(jié)構(gòu)，更改字段，新增字段，更改字段名稱一般都是通過ALTER TABLE ?TABLENAE 語法進(jìn)行修改的。對于測試庫，在線小表或者并發(fā)訪問不是很大的情況是OK。但是如果是在線大表。那就很麻煩。由于表數(shù)據(jù)量大，復(fù)制表需要比較長的時間，在這個時間段里面，表是被加了鎖的(寫鎖)，加寫鎖時其他用戶只能select表不能update、insert表。表數(shù)據(jù)量越大，耗時越長。

?

所以，對于數(shù)據(jù)量大的表，數(shù)量很大。在線修改表結(jié)構(gòu)一直是一個頭痛的問題，因為互聯(lián)網(wǎng)應(yīng)用的一大特點不能影響用戶正常使用，否則用戶會慢慢流失掉。

?

?

有些公司碰到的表數(shù)據(jù)很小，幾萬到幾十萬行數(shù)據(jù)一張表，可能還不會遇到應(yīng)用卡死的問題。所以我們網(wǎng)站在跑，開發(fā)個新功能，需要加個新字段,經(jīng)常是直接操作不會影響什么(何況只是延遲寫入操作而已,呵呵)

看這幾篇文章就知道了：

1、http://wiki.hexnova.com/pages/viewpage.action?pageId=2031684?mysql在線修改表字段造成的鎖表

2、http://hidba.org/?p=795

3、比如就有人專門在加字段之前進(jìn)行測驗mysql是否復(fù)制表，以減低應(yīng)用卡死的風(fēng)險：http://www.cnblogs.com/zuoxingyu/archive/2013/03/28/2986715.html

拷貝表結(jié)構(gòu)，然后插入少量的數(shù)據(jù)。去修改表結(jié)構(gòu)。看影響的行。如果為0，則表示不會拷貝中間表的方式

?

?

?

目前業(yè)界實踐出了一些成熟的解決辦法：

1、很多公司以前的做法是：停掉mysql服務(wù)器來修改表結(jié)構(gòu)。然后進(jìn)行滾動式更新。比如很多臺mysql服務(wù)器。先修改主服務(wù)器的表結(jié)構(gòu)，把這臺服務(wù)器停掉來更新(一般多臺主服務(wù)器，讓其他主服務(wù)器提供服務(wù))。等到更新完，就滾動到從服務(wù)器(在此之前是其他從服務(wù)器提供服務(wù)的)。其實想想發(fā)現(xiàn)有個弊病：修改表結(jié)構(gòu)要等到很長時間才能生效。mysql服務(wù)器越多，就需要的時間越長。那我可以理解：假設(shè)需要幾天，那只有等到更新完畢。才能把代碼丟上去，因為表結(jié)構(gòu)沒有更新完畢，新的程序操作新的字段會出錯的。

?

從馮大輝那篇文章那里聽說，Facebook數(shù)千臺MySQL服務(wù)器在過去增加個索引需要幾個月的滾動升級(后來他們自己開發(fā)了后面提到的工具，只需要幾天)

?

能夠停掉mysql服務(wù)器來修改字段，這就好辦,時間長也無所謂,呵呵，至少用戶不會使用你網(wǎng)站的時候卡死吧。但是互聯(lián)網(wǎng)應(yīng)用往往不能影響用戶使用，所以很多公司盡量是在凌晨的時候進(jìn)行操作(這個時候訪問用戶少，對用戶影響就小)

比如像這個例子：http://www.mysqlops.com/2011/03/30/myisam-innodb.html

表的數(shù)據(jù)量上億。要把表的存儲引擎從myisam改為innodb(我覺得存儲結(jié)構(gòu)都不同了，轉(zhuǎn)換需要時間更長)，但是他是停掉mysql服務(wù)器操作的。

阿里巴巴的馮大輝分享中也提到，業(yè)務(wù)應(yīng)用大，需求就會頻繁變化。所以就經(jīng)常涉及到修改數(shù)據(jù)庫字段，在線的調(diào)整字段是要考慮很多的問題的。作者認(rèn)為，目前沒有特別的方法來解決這個問題(技術(shù)是適應(yīng)需求變化，支撐運營的)。他說豆瓣對此也很頭痛，只能把服務(wù)器短暫的停一下。

?

2、測驗法。加字段，加索引，先在測試環(huán)境模擬測試一下需要多長時間。免得服務(wù)器生產(chǎn)環(huán)境正式加的時候,應(yīng)用卡死了，好有個預(yù)期準(zhǔn)備。

我記得以前在a公司,表數(shù)據(jù)量也上千萬,壓根就沒這種測驗吧，大白天，就直接加字段和索引,反正我也不知道前臺影響如何,當(dāng)時我也沒這個經(jīng)驗,何況我也不是技術(shù)負(fù)責(zé)人,呵呵，技術(shù)負(fù)責(zé)人都沒不清楚這個，我那就更加沒了，那個技術(shù)經(jīng)理是做企業(yè)級開發(fā)的，跟web開發(fā)環(huán)境和思維方式是不同的,他不清楚會存在這些影響吧，再說，當(dāng)時在加的時候沒法湊巧用戶投訴說，網(wǎng)站無法下單了啊,沒這么巧的情況。其實從我現(xiàn)在理解角度來看，我絕對會更加嚴(yán)格點。

?

前面也提到了，國外有人研究修改表結(jié)構(gòu)會不會復(fù)制一張臨時表，就看"rows affected?“的值。如果為0，則表示不會拷貝中間表的方式,這樣子就很快的。我沒試過

?

3、使用專門的輔助工具。一些公司開發(fā)了自己的內(nèi)部工具來輔助進(jìn)行。比如facebook。

另外騰訊的技術(shù)也介紹了他們自己定制的tmysql進(jìn)行在線加字段的實現(xiàn)原理：

http://www.zhdba.com/mysqlops/2013/09/14/mysql-innodb-online-ddl/

?

facebook自己開發(fā)的工具，官網(wǎng)：

http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/tools/files/head:/osc

?

?

----------------------------------------------------------------------

我記得好像最先是facebook進(jìn)行了方案創(chuàng)新(呵呵，當(dāng)你的遇到的是復(fù)雜問題,沒有人解決過就只能先創(chuàng)造新的技術(shù)方案了)，當(dāng)時馮大輝專門寫了一篇，其他文章介紹他們的創(chuàng)新。其他工具都是跟這個思路差不多的。不過我下載了facebook官網(wǎng)的，是用php實現(xiàn)的。沒具體看。因為下載的包里面都是php文件。

?

?

總的來說，這些工具大致的理大同小異：表結(jié)構(gòu)的修改在創(chuàng)建的一張新表中執(zhí)行(這樣不需要鎖定原表了，也就不會影響mysql提供服務(wù))，更為關(guān)鍵的是解決了一個問題，當(dāng)這個間隔時間內(nèi)，用戶在使用mysql，對表數(shù)據(jù)進(jìn)行了更新怎么辦？

?

工具的解決辦法思路是，在原表中創(chuàng)建幾個觸發(fā)器針對uptate、delete 、insert操作都記錄下來，這樣子把對原表的操作記錄下來，方便更新到新建立的臨時表中中去。

?

?

聽過豆瓣網(wǎng)的架構(gòu)變遷分享會中提到，他們以前在這方面也吃過苦頭的，一張很大的表(比如上千萬)，在線加個索引，由于數(shù)據(jù)量大，整個應(yīng)用就卡死了。

其實有時候卡幾個小時可能都很正常。死鎖了嘛。另外對臨時表要進(jìn)行復(fù)制數(shù)據(jù)，建立這個臨時表也需要時間嘛。

?

他們現(xiàn)在用的辦法是：先拷貝一張一模一樣的表，數(shù)量也是差不多，先在這張表上面測試，看看需要多長時間。如果幾分鐘，是在可以接受的時間范圍內(nèi)，就可以。如果幾個小時就不行了。這樣子提早預(yù)先知道。

另外，也使用了online-schema-change這個工具。

?

關(guān)于online-schema-change

是percona推出的一個針對mysql在線ddl的工具

percona是一個mysql分支維護(hù)公司，專門提供mysql技術(shù)服務(wù)的。我的理解，類似于linux的分支redhat公司

官網(wǎng)下載地址為：http://www.percona.com/redir/downloads/percona-toolkit/2.2.1/percona-toolkit-2.2.1.tar.gz

?

騰訊，淘寶，百度這些公司多少都有自己開發(fā)的工具來解決這個頭痛的問題。

?

?

另外，mysql5.5企業(yè)版是支持在線ddl了，不過企業(yè)版要收費嘛

?

MySQL 5.6改進(jìn)了安全功能，例如對關(guān)鍵配置文件和用戶密碼的加密方式，但是對InnoDB的提升才是大新聞。使用該存儲引擎的最后一個主要障礙便是缺少全文索引，但是現(xiàn)在這個問題已經(jīng)不復(fù)存在了。

該版本還為InnoDB引入了在線DDL，DBA一定會非常喜歡這個功能。增加、重命名和刪除列等常用的操作可以和并發(fā)查詢同時執(zhí)行。盡管可能涉及到一些數(shù)據(jù)的復(fù)制或重組，但是大多數(shù)在線DDL操作都能夠就地執(zhí)行。

?

轉(zhuǎn)載于:https://www.cnblogs.com/wangtao_20/p/3504395.html

總結(jié)

以上是生活随笔為你收集整理的mysql在线修改表结构大数据表的风险与解决办法归纳的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。