mysql cpu 突然上去_MySQL所有的压力都在一个CPU核心上，为什么会产生这种现象，该如何解决？...

目录

大表，某列无索引，先需要查询该列，删除符合条件的记录，大约占40%数据量，请问有何更好的方案吗？

MySQL所有的压力都在一个CPU核心上，为什么会产生这种现象，该如何解决？

监控MySQL的性能，应该主要观察那几个监控项？

一、大表，某列无索引，先需要查询该列，删除符合条件的记录，大约占40%数据量，请问有何更好的方案吗？

(一)存在其他索引(主键、唯一索引、普通索引)的情况

1、可利用现有索引分段扫描全表，例如每次只读取1000条记录，然后再根据条件进行判断并删除数据(最好是进行归档，而不是真正删除)。

2、由于要删除掉的数据量比较大，会造成InnoDB表较多碎片，可以考虑用反向操作，也就是创建新表，把要保留的数据复制过去，最后再将两个表对调。

3、利用pt-archiver工具进行归档。

(二)无任何索引的情况

1、真发生这种情况的话，负责的DBA或者相关同学麻烦引咎辞职吧。这句话是开玩笑的，嘿，不过说真的也太挫了。

2、观察条件列，如果区分度较高(不同值较多)，就创建一个新索引，再根据索引删除数据。

3、对该表创建一个自增主键列，然后参考上述方案，根据主键索引分段扫描、判断、删除(归档)。

二、MySQL所有的压力都在一个CPU核心上，为什么会产生这种现象，该如何解决？

(一)为什么会产生这种现象？

事实上，并不是所有压力都在一个逻辑CPU上，其实是因为MySQL还不支持并行计算，因此一个会话中的SQL只会被分配到一个逻辑CPU上。

之所以出现这种现象，大概率是因为下面几种情况：

1、某个会话中正在执行慢SQL，尚未结束；

2、某个会话中的SQL开启了大事务，并且持有很多行锁或等待很多行锁，该事务尚未结束

(二)如何解决?

1、检查是否有慢SQL，并进行优化

2、尽量不使用大事务，拆分成小事务

3、记住老司机的名言，当mysqld进程消耗CPU很高时，极大概率是有些SQL没索引导致

4、也可以尝试用perf top工具来排查具体什么原因导致

三、监控MySQL的性能，应该主要观察那几个监控项？

(一)liunx操作系统层面

1、整体cpu负载的%user最好不长期超过20%(若%user太高，有极大可能性是索引使用不当)

2、整体cpu负载的%iowat最好不长期超过10%(确认I/O子系统是否有明显瓶颈)

3、整体cpu负载的%idle最好保持在70%以上(让CPU保持低负载)

4、关注各个逻辑CPU之间的负载是否均衡(可能是中断不均衡导致性能问题)

5、关注是否有swap产生(注意关闭NUMA)，可使用命令或工具：vmstat、sar、dstat等

(二)MySQL状态层面

1、主要关注tps、qps、并发连接数(Threads_connected)、并发活跃线程数(Threads_running)、临时表(tmp_disk_tables)、锁(locks_waited, Innodb_row_lock*)等指标

2、关注当前是否有不良线程状态，例如：copytotmp table、Creating sort index、Sorting result、Creating tmp table、长时间的Sending data等

3、关注InnoDB buffer pool page的使用情况，主要是Innodb*pages_free、Innodb*wait_free两个

4、关注InnoDB的redo log刷新延迟，尤其是checkpoint延迟情况，并关注unpurge list大小

5、关注innodb status中是否有long semaphore wait的情况出现

6、关注slow query sql的增长情况