mysql如何排查CPU占用

让我告诉你我遇到 MySQL CPU 峰值的一次经历。

几年前，我们的一个电子商务项目突然陷入停滞。
当我查看背景时，我看到 CPU 已满并且正在大声燃烧。
赶紧用top上移，按P排序，哦，mysqld占了一半多了！此时，我的心里猛地一“重击”——是的，MySQL内部一定有问题。

然后快速连接MySQL，SHOW PROCESS LIST；输入一下，哦，有很多查询处于“正在运行”状态，其中一个查询运行了将近一分钟！难道不应该检查一下慢查询日志吗？快速打开慢查询日志。
我记得是/var/log/mysql/slow.log。
当时的结构是这样的： sql 设置全局 Slow_query_log = 'ON'; 设置全局 long_query_time = 1 ; 设置全局 log_output = '文件'; SET GLOBAL Slow_query_log_file = '/var/log/mysql/slow.log';
然后将long_query_time设置为1 秒，运行一段时间，然后使用mysqldumpslow找到受影响最大的区域： 巴什 mysqldumpslow -s c -t 1 0 /var/log/mysql/slow.log
一看，原来有一个查询“SELECT FROMorders WHERE user_id = 1 2 3 ”执行频繁，执行了上千次，扫描了几十万行！当时我就觉得这个SQL需要改一下，资源不应该这样浪费。

接下来我将使用EXPLAIN来查看执行计划： sql EXPLAIN SELECT FROMorders WHERE user_id = 1 2 3 ;
乍一看，类型为ALL（全表扫描），键为NULL（无索引），行数极大（估计要扫描几十万行）。
那不是很慢吗？快速添加索引： sql ALTER TABLE 命令 ADD INDEX idx_user_id (user_id);
添加索引后，再次运行它，嘿，很快，几秒钟就出来了！那时的感觉真好。

后来我用innotop实时查看MySQL的线程和锁状态，发现有时确实有锁在等待。
还有 Performance_schema。
虽然当时我不熟悉它，但我发现它非常有用。
还有系统原理图。
我正在查看一个名为 sys.statement_analysis 的视图。
我可以很快看到哪个SQL最慢，这也很方便。

最后，我还增加了 innodb_buffer_pool_size。
当时服务器内存比较大，所以我设置为物理内存的6 0%。
还有max_connections，之前设置得太低，后来相应增加了。

一般来说，当MySQL CPU如此高时，很可能是由于查询速度慢、锁争用、配置不当或并发过多造成的。
排查问题时，首先检查上面是否是mysqld的问题。
然后查看 SHOW PROCESSLIST 发现明显慢速的查询。
然后打开慢查询日志并使用mysqldumpslow找到受影响最严重的区域。
然后查看执行计划并使用 EXPLAIN 找出问题所在，例如比如是否没有索引、是否有全表扫描等，最后检查配置是否合适。
如果还是不行，请再次检查锁的情况或者只是添加硬件。

这件事给了我深刻的教训。
是在未来定期检查、监控慢查询日志、检查索引使用情况是必要的，可以防止许多重大问题。

mysql经常占用cpu100%以上，该怎么解决

抱歉，我以前确实遇到过这种情况。
我记得那是2 01 6 年，当时我在一家互联网公司做技术支持人员。
有一次，我们公司的一个线上系统突然卡住了，CPU占用率达到了9 0%以上。
多么痛苦啊。
后续排查发现，某业务模块在处理大量数据时，无法很好地处理并发访问，导致数据库访问过于频繁。

当时我们团队花了两天时间才解决这个问题。
首先，我断开网络并让数据库在没有访问权限的情况下运行。
结果是 CPU 使用率立即下降。
然后我们分析了数据库的访问日志，发现一些SQL语句写得不好，导致数据库处理起来非常困难。

最后，我们优化了这些SQL语句并减少了命中次数。
这件事给我留下了深刻的印象。
以后我会知道如何解决类似的数据库访问问题。
哎，说来也奇怪，有些人就是喜欢胡乱写SQL，不考虑数据库的健壮性。
对此，我见过好几个SQL语句写得不好，导致数据库过载的案例。
最终只能通过优化来解决。