点击标题下「蓝色微信名」可快速关注
无论是应用还是数据库，消耗过多CPU导致的性能问题，是个比较常见的场景，排查的路径因技术的不同可能略有差异。Oracle数据库SQL过度消耗CPU的问题场景排查过程可以参考《如何捕获问题SQL解决过度CPU消耗的问题》，Java Full GC导致CPU消耗过多的问题场景排查过程可以参考《一个Full GC次数过多导致系统CPU 100%的案例排查》，杨老师写的这篇文章《某个SQL导致数据库CPU飙高，如何快速定位？》则讲解了MySQL数据库定位CPU消耗过多的SQL语句的过程，值得学习参考。
MySQL数据库定位，可以用如下简单例子说明，主要是了解如何定位的思路，具体看官网介绍，参考：
https://www.percona.com/blog/2020/04/23/a-simple-approach-to-troubleshooting-high-cpu-in-mysql/
主要意思是针对定位CPU的问题，Percona增加了对通过信息的TID列将processlist ID映射到OS线程ID的支持，而MySQL在5.7版本后在PERFORMANCE_SCHEMA.THREADS表加了一个THREAD_OS_ID新列来实现，以下方法适用于在其他内核正常运行时，某个特定CPU的查询过载的情况。
find out which session is using the most CPU resources in my database?
定位线程
pidstat -t -p 1 5
通过该命令我们可以定位到**「802、4445等线程消耗了大量的CPU」**，这里尽量确保在pidstat的多个样本中验证消耗是恒定的。根据这些信息，我们可以登录到数据库，并使用以下查询找出哪个MySQL线程是罪魁祸首。
定位问题
select * from performance_schema.threads where thread_os_id = xx ; select * from information_schema.`PROCESSLIST` where id=threads.processlist_id
根据操作系统id可以到processlist表找到对应的会话，如下，
查看问题SQL执行计划
对应看下执行计划基本就可以判断当前数据库CPU为什么消耗这么高了。
至于优化的操作，只需要在dock建一个索引即可，
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"和"在看"，或者直接转发朋友圈，
近期更新的文章：《资料分享 - 实现CMDB数据准确的思考与实践》《并发和并行是一个概念么？》《INSERT UPDATE导致MySQL Crash的场景解惑》《MySQL大表增加唯一索引场景》《Windows的匿名登录》
近期的热文：《推荐一篇Oracle RAC Cache Fusion的经典论文》
《"红警"游戏开源代码带给我们的震撼》
文章分类和索引：《公众号1400篇文章分类和索引》
