一、說明
故事的開始是這樣的，表中某個字段類型varchar(3)，根據業務需要改爲varchar(6)，這些都是正常的。DBA需要做的工作如下：
1、查看存儲空間
df -h
2、查看錶大小
50G大表
3、查看錶結構
show create table xxx\G;
4、官方查看是否支持online DDL，是否會重建表、是否表鎖等，分析對系統的影響，主從複製是否延遲等等。
5、測試環境進行測試
敲黑板的時候到了，DBA通常就是直接登錄數據庫執行命令，這沒毛病，經過多次測試毫秒級別執行完成，驗證表結構正確，不會影響業務，搞定通知開發~
二、結果
同樣的命令在生產環境執行花費了40多分鐘，show processlist發現顯示altering table，出現了異常的情況，不可能，不應該，但遇到問題就面對就好了，一切的異常都是有原因的，把自己當成偵探，來探個究竟吧~
三、分析
1、命令是相同的不存在問題。
2、使用的工具是不同，懷疑？？？？
3、現象告訴我們表可能是在rebuilding，爲什麼會這樣。
4、這個時候需要進一步分析，這相當於是一個事後分析，對MySQL來說很難，這個時候不要輕易懷疑官方文檔出錯。把表結構拿出來看，你要足夠的有耐心和細心，表修改前後有什麼變化，你會發現not null的限制變成了default null，我們沒有修改這個限制啊，再去看官方online DDL，你會發現這個操作是需要rebuilding table，大喜，感覺好像找到了答案。使用navicat工具做幾次測試來驗證，現象復現了，也得到了驗證。最後推論出navicat的這個坑。最後，喜歡使用navicat的小夥伴可以自己測試一下，一定要親測。
四、結論
1、DBA不喜歡用工具原因之一是避免工具本身的坑，因爲一個坑可能會造成一次重大事故，承擔不起。
2、日常工作現場環境很複雜，給你的只是一臺甲方的生產機，沒有你想要的工具，難道你就束手無策了，命令行最直接，也可以分析個大概。
3、習慣要養成，並不是爲了裝X，這也是你的老闆感覺你值得的原因。
4、不要怕坑，生活到處都是坑，不要追究是誰挖的坑，坦然面對就好，你存在的意義就是能從坑裏爬出來，繼續前進。