我理解題主問的是有100個表,這100個表結構完全一樣,要給這100個表“同時”alter table,而不是在這100個表上面同時update資料。結論是:沒什麼好的辦法,只能挨個改。這裡面涉及兩個問題:1.表比較大的情況下,改表結構鎖表時間很長;有主從同步的時候,改表會導致從庫延遲。這個可以用pt-online-schema-change 來解決,可以把改表結構對線上系統的影響降到最低(用新結構建空表-逐條複製資料-rename,同時用觸發器保證複製過程中對資料的增刪改也應用到新表上,這些操作都可以不引起可觀延遲地同步到從庫)2.改表結構有先後,改的過程中不能保證每個分表結構一致。如果正常挨個改的話,不一致是肯定存在的,沒法解決,只能讓程式儘量相容。或者用online-schema-change類似的思路,把改表的前兩個步驟做了(建空表,複製並同步資料),最後統一rename,這樣其實還是有一瞬間100個表不完全一致,但是能把不一致的時間縮短到最小。——以前某公司就有這樣的100個表,而且 ORM還在記憶體中快取了表結構,導致改表結構造成的影響很大。最早的時候一改表結構程式碼就報錯,因為有表結構快取,只要結構變了拼的SQL語句就會出問題,只能改完立刻重啟web服務清除快取。為了解決這個問題,就改用mysql返回的metadata來生成ORM物件,讓讀查詢都脫離這個表結構快取。然後對這種100個表不一致問題,在這100個表之外建一個單獨的結構表xxx_struct,這個表不存資料,只用它來生成表結構快取,在改表結構的流程上做個規範,加欄位的時候先改存資料的表結構,然後再改_struct,刪欄位相反,總之保證_struct表比真實表字段少,就沒啥問題了。
我理解題主問的是有100個表,這100個表結構完全一樣,要給這100個表“同時”alter table,而不是在這100個表上面同時update資料。結論是:沒什麼好的辦法,只能挨個改。這裡面涉及兩個問題:1.表比較大的情況下,改表結構鎖表時間很長;有主從同步的時候,改表會導致從庫延遲。這個可以用pt-online-schema-change 來解決,可以把改表結構對線上系統的影響降到最低(用新結構建空表-逐條複製資料-rename,同時用觸發器保證複製過程中對資料的增刪改也應用到新表上,這些操作都可以不引起可觀延遲地同步到從庫)2.改表結構有先後,改的過程中不能保證每個分表結構一致。如果正常挨個改的話,不一致是肯定存在的,沒法解決,只能讓程式儘量相容。或者用online-schema-change類似的思路,把改表的前兩個步驟做了(建空表,複製並同步資料),最後統一rename,這樣其實還是有一瞬間100個表不完全一致,但是能把不一致的時間縮短到最小。——以前某公司就有這樣的100個表,而且 ORM還在記憶體中快取了表結構,導致改表結構造成的影響很大。最早的時候一改表結構程式碼就報錯,因為有表結構快取,只要結構變了拼的SQL語句就會出問題,只能改完立刻重啟web服務清除快取。為了解決這個問題,就改用mysql返回的metadata來生成ORM物件,讓讀查詢都脫離這個表結構快取。然後對這種100個表不一致問題,在這100個表之外建一個單獨的結構表xxx_struct,這個表不存資料,只用它來生成表結構快取,在改表結構的流程上做個規範,加欄位的時候先改存資料的表結構,然後再改_struct,刪欄位相反,總之保證_struct表比真實表字段少,就沒啥問題了。