业务期间,MySQL小表的DDL会酿成事故么？

开发提交的SQL如下，对一个小表加索引，可以看出这个个表大致是57万行左右，理论上这个表在业务高峰期执行是有不会有问题的

是的，因为确认是小表的DDL，直接点击执行了，大概等了20秒左右，没有返回执行成功，习惯性的觉得这个可能会有问题，登陆腾讯云web 后台查看的进程截图如下

这是一小部分截图，首先你发现这个alter语句处在一个等待元数据的状态中，即是Waiting  for table metadata lock
状态中 ,并且已经有几十条的insert  into 也处于这个状态，试想如果没有去查看，而是等待执行结果，可能就会酿成线上的一次大的事故，据此推测
在DDL执行之前，肯定有对同一个表的操作语句，并且应该是一个执行比较慢的语句，导致小表DDL语句一直处于等待获取元数据锁的过程中，DBA迅速保留了快照，然后kill掉了DDL语句，insert  into  语句
瞬间全部执行，线上业务未能感知到这个问题，但是如果你一直等待，或者点击执行就完事了，你就有可能酿成大的生产事故，再回看当时保留的快照，发现下面的SQL：

在你执行小表DDL的之前，上述的SQL一直在运行中，c表是小表，但m表是大表，这个SQL的性能极差，下面是它的执行计划，这种慢SQL就是隐藏在背后的罪魁祸首，它导致你的小表DDL一直处在等待元数据锁中，你如果熟悉DDL的一个执行过程，你就能明白select语句为什么会一直导致你的DDL处在等待元数据锁的状态中。

而这个SQL是某开发刚好有一个临时的数据需求，在查看数据，所以个人认为，在业务期间执行SQL，首先一定要严谨，有风险，不执行，没风险，执行期间，你可以去查看对应进程以及数据库服务器的一个监控状态，这样你就能确保万无一失，避免生产事故！

多多关注，一起探讨，一起成长，欢迎留言，欢迎关注MySql星探！