记一次truncate导致的锁表处理

一个不是很大的表，由数据分析部门生成并用于业务。由于代码发了新版需要第一次运行，所以在业务低峰期让数据部门执行了，逻辑是先truncate再insert重建。由于一直以来都没问题，觉得不会出错。结果过一会儿悲剧了，告警来了，app首页空白。。。

这种牵一发而动全局的故障，基本都是mysql引起。先看现象：

1. cpu不高，很平稳
2. 慢查询正常
3. 连接数很高

这种很可能是锁表。进去一看processlist果然，那个truncate卡在那里，然后一堆线程在wating for meta data lock...  kill后故障恢复，数据表改由delete清空

由这个例子讲一下：

• 锁表或db hang的一个显著表现就是connection飙升，这是由于连接池的行为，查询无法返回就新开连接重查。严重时可以耗尽connection limit
• truncate应慎重，它属于ddl，会lock table meta data，甚至可能由锁表升级为锁库
• 业务错综复杂，首页的推荐居然依赖数据分析...... 所以有了开头那个app空白的尴尬。相关人当然已经被怼啦，哈哈