这篇文章主要介绍“MYSQL生产环境字段更改的失败的问题如何解决”,在日常操作中,相信很多人在MYSQL生产环境字段更改的失败的问题如何解决问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答“MYSQL生产环境字段更改的失败的问题如何解决”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!
早上看到微信一个银行的同学问了小问题,希望他不要背锅,具体问题是MYSQL一个50克的表要更改字段,将一个字段从varchar (3),改成varchar (6)。,MYSQL 5.7官版。因为根据官方和在测试系统测试的结果来看,不应该是缓慢的,应该是很快完成的。
<强>所以我们要理解一个事情首先要站在一个起跑线上,上面的东西都是官方文档,并且在测试环境上测试基本上没有太大问题。
可能原因如下
1,DDL alt=" MYSQL生产环境字段更改的失败的问题如何解决">
alter table test1修改列content varchar(201),算法=原地,锁=没有;
但实际上,这条语句一直在等待的状态,根据官方文档,如果他在执行的时候,应该是不会对DML操作有影响。但如果他根本就在等待元数据锁呢。所以修改字段的任务依然是失败的。
到底是为什么,官方在文档中明确了
为了确保事务的可串行性,服务器必须不允许一个会话对另一个会话中未完成的显式或隐式启动的事务中使用的表执行数据定义语言(DDL)语句。服务器通过获取事务中使用的表的元数据锁,并将这些锁的释放推迟到事务结束时,来实现这一点。表上的元数据锁可以防止对表结构的更改。这种锁定方法意味着一个会话内的事务正在使用的表,不能在DDL状态下使用。
但让我感到奇怪的事情是,当我停止了存储过程不断对这个表进行操作,DDL的语句也未在执行,并且就卡在哪里。
而在消灭掉所有的有关线程后,再次做这个实验,惊奇的是不在有MDL锁来阻碍改变的操作,基本上都是瞬间在0。几秒的时间就完成了。
总结一下
DB的工作本身是一件复杂的工作,他并没有你在理解原理后,就一定会按照你认为的那样,去工作,因为理论和实际遇到的情况不同,实际的情况太多种多样。
有些公司操作改变语句的并不是人工,而是通过购买(或开源)的一个所谓的“自动化”工具来的,谁也不知道在故障发生的一刻,做了什么,同时不能复制的,就是当时的生产环境到底有没有大事务,并且就对那张表进行了什么操作,那个表有几个索引,这个字段有没有索引,等等。
也注定DB的工作,是一件需要小心小心小心的工作,因为生产环境一定有你不清楚的环境,而这些可能不清楚的环境,就会让某次“信心满满”的行动失败了。
注:到目前为止MYSQL在修改字段方面,对比其他数据库还是要注意的地方多的多,当然MYSQL 8已经添加了即时让修改字段变得更让人放心。
但目前MYSQL5。X, PT-OSC, GH-OST等等的工具还是用起来,终归是不希望出现意外的情况。
下面有一个查看metadatalock的存储过程,(有点乱,可以拷贝出来,自己整理一下)
创建过程procShowMetadataLockSummary ()
开始宣布table_schema VARCHAR (64),
,,声明table_name VARCHAR (64)。
