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

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

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

2、处理办法:

a、查询新项目消耗cpu,内存:top    (正常)

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

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

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

网上查询system lock  含义:

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

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

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

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

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

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虽然快 好用,但是在系统层面还是得慎用,特别是使用频次较高的时候。

上一篇:MYSQL主从不同步延迟原理分析及解决方案(摘自http://www.jb51.net/article/41545.htm)


下一篇:mysql的线程处于System lock状态下