整理這篇文章的緣由：
互聯網應用會頻繁加功能，修改需求。那麼表結構也會經常修改，加字段，加索引。在線直接在生產環境的表中修改表結構,對用戶使用網站是有影響。
以前我一直為這個問題頭痛。當然那個時候不需要我來考慮,雖然我們沒專門的dba，他們數據量比我們更大，那這種問題也會存在。所以我很想看看業界是怎麼做的,我想尋找有沒有更高級的方案，呵呵，讓我覺得每次開發一個新功能，我在線加字段都比較糾結。後來只知道，不清楚在什麼時候，無意中看到一個資料介紹online-schema-change這個工具，於是順便搜出了不少東西。後來逐漸發現騰訊，淘寶他們都會存在這種問題，我發現解決思路都差不多。具體看完我這篇歸納的文章
由於mysql在線ddl(加字段、的索引等修改表結構之類的操作）過程如下：
A.對表加鎖(表此時只讀)
B.復制原表物理結構
C.修改表的物理結構
D.把原表數據導入中間表中，數據同步完後，鎖定中間表，並刪除原表
E.rename中間表為原表
F.刷新數據字典，並釋放鎖
在這個過程中會鎖表。造成當前操作的表無法寫入數據，影響用戶使用。由於需要復制原表的數據到中間表，所以表的數據量越大，等待的時候越長，卡死在那裡(用戶被拒絕執行update和insert操作,表現就是延遲了一直在等待)。
其實就是對表加了個排它鎖，這個時候其他用戶只能讀表的數據,不能寫。想具體體驗一下是什麼效果，我以前測驗對mysql的表加鎖，操作的時候是如何的：http://www.cnblogs.com/wangtao_20/p/3463435.html
平時進行修改表的結構，更改字段，新增字段，更改字段名稱一般都是通過ALTER TABLE TABLENAE 語法進行修改的。對於測試庫，在線小表或者並發訪問不是很大的情況是OK。但是如果是在線大表。那就很麻煩。由於表數據量大，復制表需要比較長的時間，在這個時間段裡面，表是被加了鎖的(寫鎖)，加寫鎖時其他用戶只能select表不能update、insert表。表數據量越大，耗時越長。
所以，對於數據量大的表，數量很大。在線修改表結構一直是一個頭痛的問題，因為互聯網應用的一大特點不能影響用戶正常使用，否則用戶會慢慢流失掉。
看這幾篇文章就知道了：
1、http://wiki.hexnova.com/pages/viewpage.action?pageId=2031684 mysql在線修改表字段造成的鎖表
2、http://hidba.org/?p=795
3、比如就有人專門在加字段之前進行測驗mysql是否復制表，以減低應用卡死的風險：http://www.cnblogs.com/zuoxingyu/archive/2013/03/28/2986715.html
拷貝表結構，然後插入少量的數據。去修改表結構。看影響的行。如果為0，則表示不會拷貝中間表的方式
目前業界實踐出了一些成熟的解決辦法：
1、很多公司以前的做法是：停掉mysql服務器來修改表結構。然後進行滾動式更新。比如很多台mysql服務器。先修改主服務器的表結構，把這台服務器停掉來更新(一般多台主服務器，讓其他主服務器提供服務)。等到更新完，就滾動到從服務器(在此之前是其他從服務器提供服務的)。其實想想發現有個弊病：修改表結構要等到很長時間才能生效。mysql服務器越多，就需要的時間越長。那我可以理解：假設需要幾天，那只有等到更新完畢。才能把代碼丟上去，因為表結構沒有更新完畢，新的程序操作新的字段會出錯的。
