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雖然快 好用，但是在系統層面還是得慎用，特別是使用頻次較高的時候。