我理解題主問的是有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表比真實表字段少，就沒啥問題了。