MySQL CPU占用过高时，应先用top确认是否mysqld进程导致，再通过SHOW PROCESSLIST和EXPLAIN定位低效SQL，最后优化索引、配置及避免函数运算等诱因。
MySQL CPU 占用过高，核心思路是“先定位、再归因、后优化”。重点不是看整体CPU百分比，而是确认是不是
mysqld 进程本身
在消耗CPU，以及它正在执行什么操作。
确认是否 mysqld 导致 CPU 高
用
或
查看进程级占用：
运行
，关注
列，找到
对应的 PID
若非 mysqld（比如 Java 应用或 cron 任务），就不用深入 MySQL 层面
进一步聚焦：用
查看 mysqld 内部哪些线程最忙（注意 TID）
查当前活跃 SQL 和执行状态
登录 MySQL，快速识别“正在干坏事”的查询：
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
执行
，重点关注
是
、
、
或
的连接
过滤非空闲会话：
对可疑 SQL 执行
临时止损（生产环境慎用）
分析慢查询和执行计划
CPU 高往往源于低效 SQL，尤其是没走索引、大量排序/分组、子查询嵌套深的语句：
开启慢查询日志（
，
），重启后收集典型负载时段日志
用
分析问题 SQL，重点看：
–
是否为
（全表扫描）
–
是否用了索引
–
是否含
、
常见诱因：
无覆盖索引、
字段未建索引、
未转成
、
条件中对字段做函数运算（如
）
检查配置与资源瓶颈
有些高 CPU 并非 SQL 本身问题，而是配置不合理放大了开销：
和
过小 → 导致频繁磁盘临时表（
），建议设为 64M~256M（需匹配内存）
过小 → 缓存命中率低，反复读磁盘+解析页，CPU 被 IO 等待掩盖但实际在忙调度
连接数爆满（
接近
）→ 线程上下文切换开销剧增
锁争用严重：查
和
中的死锁片段
tophtoptop -c%CPUmysqldtop -Hp [PID]SHOW FULL PROCESSLIST;StateSending dataCopying to tmp tableSorting resultCreating sort indexSELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND != 'Sleep' AND TIME > 2;KILL [ID]slow_query_log = 1long_query_time = 2EXPLAINtypeALLkeyExtraUsing filesortUsing temporaryORDER BY + LIMITGROUP BYIN (subquery)JOINWHEREDATE(created_at)tmp_table_sizemax_heap_table_sizeCopying to tmp table on diskinnodb_buffer_pool_sizeThreads_connectedmax_connectionsSELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;SHOW ENGINE INNODB STATUS;