MySQL中如何快速定位占用CPU过高的SQL

作为DBA工作中都会遇到过数据库服务器CPU飙升的场景,我们该如何快速定位问题?又该如何快速找到具体是哪个SQL引发的CPU异常呢?下面我们说两个方法。聊聊MySQL中如何快速定位占用CPU过高的SQL。

技术人人都可以磨炼,但处理问题的思路和角度各有不同,希望这篇文章可以抛砖引玉。

 

以一个例子为切入点

基础环境:

  • 主机类型:阿里云 
  • 操作系统:CentOS release 7.4
  • 存储:Alibaba Cloud ECS    
  • 内存:64 G
  • CPU型号:Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz ( 1 U * 8 core) 
  • CPU核数:16CORE
  • 数据库环境:MySQL5.7.27
  • 存储引擎:InnoDB

 

问题现象:

数据库服务器CPU飙升。

方案一、通过pidstat命令定位

首先我们先找到mysqld进程的PID,然后执行pidstat -t -p $PID,结果如下图:

 

进入mysql交互命令,通过以下命令查询具体SQL。
 select * from performance_schema.threads where thread_os_id = '1';
定位到了具体定位sql接下来就可以分析优化了。

方案二、通过TOP命令定位
  • 首先执行TOP命令,输入H,可以按照显示线程状态。
  • 输入P,可以按照cpu的使用时间份额进行排序,这时候我们就可以看下是否有超过70%-90%以上的线程了。



登录mysql,执行以下命令

select * from performance_schema.threads where THREAD_OS_ID=4461 \G


 

posted on   数据与人文  阅读(130)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
历史上的今天:
2021-09-16 对RMAN保留策略 RECOVERY WINDOW 的重新认识
2020-09-16 oracle 11.2.0.4bug-->sysauth$ 存在登录查询的bug:High CPU/IO for dictionary SQL against SYSAUTH$
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

点击右上角即可分享
微信分享提示