CPU突然高达800%会是什么原因造成的，32核为例？
最可能是锁的问题
1、top –Hp 进程
可以找到打满CPU的线程是哪个，对应的pid就是performance_schema.threads表中的
thread_os_id，也就能找processlist_id，通过 show processlist 找到对应的执行用户窗
口，找到相应用户信息，还可以通过performance_schema.events_statements_history 表找
到对应执行的语句。
2、%Cpu(s): sy us wa
CPU这3个状态能简单判断锁的情况，只是wait高一般跟IO有关，如果是us高的话，更可能是慢查
询导致，如果是sys和wait都高，大几率锁定是锁的问题。
锁排查完整思路：
1.元数据锁排查
1.1 show processlist; 查看自己的锁类型，案例情况下，当为 Waiting for global
read lock
1.2 select * from performance_schema.metadata_locks;
—> PENDING 对象是正在等待元数据锁，在通过库表信息，看谁锁了自己想要的元数据
—> GRANTED 对象是已经获取了元数据锁，对应上自己想要的元数据，确定
OWNER_THREAD_ID 的值
—> select * from performance_schema.threads where THREAD_ID = num;
确定 PROCESSLIST_ID 的值
1.3 show processlist; 比对 PROCESSLIST_ID 看对方是谁，正在做什么，在确认可以杀
死的话，kill Id
2. 行锁排查
2.1 确认有没有锁等待:
show status like ‘innodb_row_lock%’
Innodb_row_lock_current_waits 的值等多少，就有多少个正在锁等待
select * from information_schema.innodb_trx;
2.2查询锁等待详细信息
select * from sys.innodb_lock_waits; —> blocking_pid(锁源的连接线
程，假设等于30)
2.3 通过连接线程找SQL线程
select * from performance_schema.threads where processlist_id=30; -
–> thread_id（假设等于67）
2.4 通过SQL线程找到 SQL语句
select thread_id,SQL_TEXT from
performance_schema.events_statements_history where thread_id=67;
show processlist; —> 找到id=30的用户是谁，拿着语句向对方确认是否可以杀死，
释放锁。