mysql truncate 引起的 system lock，导致其他进程等待

1、现状：上线新项目，导致api服务延迟，cpu正常，内存正常，连接数正常，sql性能正常，sql进程正常（初步分析）

最后再次分析sql进程才发现 由于该 truncate table name ; 语句为实时执行，导致其余进程出现时间延长。影响api调用，及整个库的使用

2、处理办法：

a、查询新项目消耗cpu,内存：top    （正常）

b、同理查询数据库消耗cpu,内存（正常）

c、查看数据库进程：随时刷新可知，在system lock 情况下会等待很多进程 ：SELECT * FROM information_schema.PROCESSLIST WHERE state != '';

网上查询system lock  含义：

这种状态可能是很多种原因 ：一个线程想请求或者正在等一个表的内部或者外部的system lock；

也可能是InnoDB在执行lock tables的时候，等表级锁；

也可能是请求内部锁，比如访问相同MyISM表没有用多个mysqld服务;

并且该语句为truncate table，因此认为为表锁。

3、分析：

由于经验，删除数据truncate 肯定是最快的，并且会回收空间，这是最好的选择。

查询system lock 网上均说出现的可能为表级锁：https://www.cnblogs.com/sunss/p/6404961.html

其实不然，经过刷新进程:现象为system lock时，进程同时出现大量等待。当system lock出现频率比较高时等待多，延迟也就高，即使truncate table 很快。

因此system lock为系统锁，整个库的进程都得等待。这是是网上没人提及的。

4、truncate table 为什么会出现system lock呢：

truncate为ddl语句，会改变元数据，会lock table meta data，空间直接释放，数据丢失不易找回：该现状为：由锁表升级为锁库。影响极其严重。

因此，truncate虽然快 好用，但是在系统层面还是得慎用，特别是使用频次较高的时候。