因为公司是做网络安全的，所以会对平时设备收到的日志以对应的规则集进行解析然后存入数据库。涉及大数据，与数据库的交互量大概是3000条/秒，所以如果设备持续收日志的话，一般两天时间数据库对应表的存放的数据量大概就有5、6亿条。
有一天我突然发现后台的日志信息一直再报“队列已满”的错误信息，到数据库查询相应表的数据发现其入库的数据量也是停留在之前的数量（此时该表的数据量已经有大概1亿多条了，该信息是为下文作铺垫的）。按照以往的经验我将可能会出现的问题挨个排查了一遍，发现都没有问题，最后我在对应的数据库查看了一下该库的 线程运行 情况，情况如下 ：
入库的insert语句一共有四条线程在执行，就报了四个“Waiting for the table metadata lock”的错误，表居然被锁了，试着kill掉，可是死了马上就活了，刚开始也不懂，看到表被锁了就没有继续往下看（最关键的信息被忽略了），后问了一下公司的前辈，上图的表中我遗漏了这么一项重要的信息：
经过前辈讲解我才恍然大悟。
原来在数据批量入库的时候，组内的另一个哥们发现前台对于日志信息的查询速度有点慢，所以他的想法就是给表中他要查的字段手动加索引“Alter table 'sim_event add index ...'”，可是他犯另一个大错误就是这个表现在差不多有1亿多数据，要想成功添加得等到猴年马月了，而对于MySQL而言，如果进行一些Alter table等DDL操作时，如果该表上有未提交的事务就会报Waiting for the table metadata lock的错误。
最后重新启动数据库，kill掉不必要的线程（其实重启就好了），入库就正常了！！！
,
