数据库

开发用工具操作MySQL的一个大坑

2020-12-30 14:49:02 阅读数 4623 收藏 0

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