【问题处理】【Mysql】mysqld进程CPU占用高排查思路

一、问题背景

Linux服务器CPU占用极高,经过排查,是mysqld占用了大部分的CPU资源。需要进一步排查是什么原因导致mysqld占用飙升。
因当前并没有大量正在执行的业务,所以初步排除业务量过大导致的Mysql资源飙升。

二、原因

Mysql服务端中可能运行少数的某几个会话,这几个会话可能存在性能问题,导致资源占用消耗巨大。

三、排查

3.1 查看运行的会话数

SHOW PROCESSLIST;

在这里插入图片描述

可以看到,目前处于excuting状态的会话有四个。

3.2 查看会话具体内容

select * from performance_schema.threads;

这个命令会列出各个会话的具体信息,包括线程ID、名称、具体的会话语句、所属用户等等信息。
在这里插入图片描述
在这里插入图片描述
根据图1中四个会话的ID(蓝色部分),在当前输出的结果中找到具体的会话语句(蓝色部分)。
发现这四个会话都在执行同一条语句,这条语句的存在子查询,且进行了联表查询。根本原因是这条sql语句有误,导致查询陷入死循环,迟迟无法结束。

四、处理

4.1 临时处理方案

将这四条耗费极大资源的会话暂时关闭,即可临时解决mysql占用大的问题。

kill <会话ID>;

注:会话ID即图1中圈蓝色框框的数字。
但如果某些业务再次调用了该sql,那么资源占用将会再次飙升。

4.2 根本解决方案

根本方法便是对sql进行优化,具体优化方式在此处不做展开。


原创内容,引用请注明出处。

<think>我们正在解决MySQL数据库CPU使用率过问题。根据引用[1]和[2],我们将采用一种从操作系统线程追踪到数据库查询的方法。这种方法特别适用于定位单个CPU过载的情况(引用[2]提到,如果是普遍性CPU问题,有其他方法)。以下步骤将帮助定位导致CPU的查询。 ### 步骤1: 确定CPU的线程(操作系统层面) 使用`top`命令查看CPU使用情况,然后按`H`(大写H)切换到线程模式,观察哪些线程消耗CPU。记录下这些线程的PID(进程ID)。 ### 步骤2: 将操作系统线程ID映射到MySQL内部线程ID 在MySQL中,`performance_schema.threads`表提供了操作系统线程ID与MySQL线程ID(`THREAD_OS_ID`)的映射关系。但是,请注意,在MySQL 5.7及以上版本中,我们可以通过`performance_schema`来查询。 执行以下SQL查询,将操作系统的线程ID(步骤1中得到的PID)与MySQL的内部线程ID关联起来: ```sql SELECT THREAD_ID, NAME, PROCESSLIST_ID FROM performance_schema.threads WHERE THREAD_OS_ID = <操作系统线程PID>; ``` 这里,`PROCESSLIST_ID`就是`SHOW PROCESSLIST`中看到的ID。 ### 步骤3: 获取导致CPU的查询 通过步骤2得到的`PROCESSLIST_ID`,我们可以查看当前正在执行的查询: ```sql SELECT * FROM information_schema.processlist WHERE ID = <PROCESSLIST_ID>; ``` 或者,使用`SHOW FULL PROCESSLIST`来查看所有连接,然后根据ID找到对应的查询。 ### 步骤4: 分析查询 获取到查询语句后,使用`EXPLAIN`分析查询的执行计划,检查是否缺少索引、是否进行了全表扫描等低效操作。 ### 步骤5: 优化查询 根据分析结果进行优化,例如添加索引、重写查询等。 ### 注意事项 - 如果问题不是由单个查询引起的,而是整体负载,可能需要考虑其他方法,如引用[2]提到的另一篇博客中的案例研究。 - 另外,确保MySQL的配置合理,比如缓冲池大小(innodb_buffer_pool_size)等。 ### 示例 假设在步骤1中,我们发现一个操作系统线程PID为12345消耗大量CPU。在步骤2中,我们执行: ```sql SELECT THREAD_ID, NAME, PROCESSLIST_ID FROM performance_schema.threads WHERE THREAD_OS_ID = 12345; ``` 假设返回的`PROCESSLIST_ID`为456。然后在步骤3中: ```sql SELECT * FROM information_schema.processlist WHERE ID = 456; ``` 这将返回该连接正在执行的查询,然后我们可以进行优化。 §§相关问题§§ 1. 如何优化MySQL的配置参数以降低CPU使用率? 2. 除了定位单个查询,还有什么方法可以分析MySQL的整体性能问题? 3. 如何预防MySQL出现CPU使用率的问题?</think>### MySQL CPU 使用率排查指南 当 MySQL 出现 CPU 使用率过时,可按以下步骤系统排查: #### **1. 操作系统层面定位负载进程** ```bash top -H # 查看线程级CPU占用 pidstat -t -p <mysqld_PID> 1 5 # 监控MySQL线程 ``` - 记录消耗 CPU的线程 ID(OS TID) #### **2. 映射 MySQL 内部线程** ```sql -- 将OS线程ID转为16进制 SELECT CONV(<OS_TID>, 10, 16) AS hex_tid; -- 查询关联的MySQL线程 SELECT THREAD_ID, PROCESSLIST_ID, PROCESSLIST_INFO FROM performance_schema.threads WHERE THREAD_OS_ID = <OS_TID>; ``` - 获取 `PROCESSLIST_ID` (会话ID) 和 `PROCESSLIST_INFO` (当前SQL)[^1] #### **3. 分析负载查询** ```sql SHOW FULL PROCESSLIST; -- 查看所有运行中查询 -- 获取问题SQL的执行计划 EXPLAIN FORMAT=JSON <问题SQL>; -- 检查锁等待 SELECT * FROM sys.innodb_lock_waits; ``` #### **4. 常见优化方向** - **索引缺失**:全表扫描导致 CPU 飙升 - **锁争用**:检查 `Innodb_row_lock_waits` - **配置不当**:`innodb_buffer_pool_size` 过小引发频繁磁盘 I/O - **低效查询**:未使用索引的 JOIN/子查询 - **资源瓶颈**:`thread_cache_size` 不足导致频繁创建线程 #### **5. 实时诊断工具** ```bash # 使用Percona Toolkit pt-query-digest /var/log/mysql/slow.log # 分析慢查询 pt-mysql-summary --samples 5 --iterations 10 # 性能快照 ``` #### **6. 配置调优建议** ```ini # my.cnf 关键参数 innodb_buffer_pool_size = 70%物理内存 thread_cache_size = 100 query_cache_type = 0 # 禁用查询缓存(MySQL 8+已移除) max_connections = 合理限制连接数 ``` > **注意**:当出现单核 CPU 满载而其他核心空闲时,通常表明存在未并行化的单线程查询[^2]。若全局 CPU,需检查系统级监控(如 `vmstat 1` 看上下文切换)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

wingaso

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值