记一次Mysql加字段加不上问题排查过程

一、背景

最近在做计费重构的项目，项目开发工作基本收尾，但是遇到了一个字段加不上的问题，排查过程中也学到了一些东西，这里记录下。

二、问题

2.1 问题反馈

由于要加的字段是另外一个同事负责的内容，到我这里收到反馈说是没加上，所以就跟进一下，从技术方案文档上找到对应的alter 表 DDL语句直接执行了一把，发现执行超时了，明显有问题，执行结果显示如下：ErrorCode:2013 Lost Connection To MySQL Server during query。下面进入正式的排查过程。

2.2 表信息收集

出现这种情况就想到了两种可能，于是直接尝试百度了下：Mysql 加表字段超时。根据搜索结果初步的信息判断，有两种可能：

数据量过大
索引过多

于是查了下表，表数据量不超过500，但是索引太多是真的，而且有外键，但是直觉或者常识告诉我上面两种可能都不是真正的原因。

三、排查过程

3.1 粗略排查&解决

到这一步就直接使用show processlist 命令来看一下是不是上面执行的命令还没有结束掉，存在锁等问题。确实发现了有几个Mysql 连接出现了锁等待，信息如下：Waiting for table metadata lock 到这里就发现问题确实不简单，因为一般情况下加字段应该是很快的，所以这里直接继续请教百度了，根据如下博客中的信息进行排查：

https://www.cnblogs.com/hanybblog/p/12048005.html

执行SQL：select * from information_schema.innodb_trx发现有很多RUNNING的线程(线程号:trx_mysql_thread_id)，同时与show processlist命令中的ID相符。于是尝试kill掉会话，这里直接在可视化工具中执行kill trx_mysql_thread_id即可kill 掉。

在排查的过程中发现show processlist命令中出现的Waiting for table metadata lock信息越来越多了，也正符合博客中的描述，另外也给我增加了一点压力。于是尝试先将alter table的线程ID会话kill掉。然后执行alter table add命令，但是情况依然没有改变。

结合博客中的描述，这里很可能是因为一些不可见的Mysql 线程会话没有释放锁导致后续对该表的操作出现阻塞。另外一方面innodb_trx的线程有不少是昨天的，上面的图其实是我kill掉一些之后才截取出来的，根据提示执行select * from performance_schema.events_statements_current,也没发现异常，所以就想着将一些长时间不释放的事务会话kill掉，经过5分钟左右的kill操作之后，只剩一些当前时间段内产生的事务了，这里再执行alter table add 命令，执行成功了。问题到此解决。

3.2 其他信息

到这里也可以执行如下SQL语句查询具体的表锁信息：

#查看mysql 锁信息
select * from information_schema.INNODB_LOCKS

#查看mysql 锁等待信息
select * from information_schema.INNODB_LOCK_WAITS

当时直接根据推理信息对对应的会话进行kill,但是确实不建议在线上直接操作，测试环境就力求尽快解决问题了，所以可以结合上面的SQL更精准的缩小线程会话范围。

四、风险点

问题虽然已经解决，也写了文章记录，但是仍然有两个风险需要注意：

线上可能因为数据量大+索引多导致执行alter table add column执行时间过长，尤其是如果本身已经存在一些脏会话的话可能造成的影响更大，这里建议执行之前多收集一些信息，评估下。(这一点已经在技术方案中作为风险点抛出)
在线上排查过程中不能粗暴的kill mysql事务会话，可能导致数据不一致，需要缩小问题范围。