一、说明
故事的开始是这样的，表中某个字段类型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、不要怕坑，生活到处都是坑，不要追究是谁挖的坑，坦然面对就好，你存在的意义就是能从坑里爬出来，继续前进。