MySQL优化|数据库性能 解决mysql数据库CPU占用100%的问题，mysql数据库 cpu 100

🔥 MySQL优化 | 数据库CPU飙到100%？别慌，老司机带你飙车式排查！

💻 场景重现：那个让运维崩溃的凌晨

"叮叮叮——"凌晨3点，我被刺耳的报警声惊醒，监控大屏一片血红：MySQL CPU 100%！😱 网站响应慢得像蜗牛，用户投诉电话快被打爆...

这种场景DBA们太熟悉了！今天就手把手教你，当MySQL CPU飙到100%时，如何像老中医一样"望闻问切",快速定位问题！

🕵️‍♂️ 第一步：快速诊断三板斧

查看实时进程（急诊科听诊器）

SHOW FULL PROCESSLIST;

👉 重点观察：

• Time列：执行时间过长的SQL（>5秒就是危险信号）
• State列：出现"Sending data"、"Copying to tmp table"等危险状态
• Info列：锁定消耗资源的SQL语句

性能剖析（X光片）

-- 开启性能分析
SET profiling = 1;
-- 执行你的SQL
-- 查看分析结果
SHOW PROFILE;

会显示每个执行阶段的耗时,像这样：

| Status               | Duration |
|----------------------|----------|
| starting             | 0.000065 |
| checking permissions | 0.000010 |
| Opening tables       | 0.000025 |
| System lock          | 0.000013 |
| optimizing           | 0.000006 |
| executing            | 0.000003 |
| Sending data         | 5.211233 |  <-- 瓶颈在这！

慢查询日志（病史档案）

-- 确认慢查询日志状态
SHOW VARIABLES LIKE 'slow_query_log%';
-- 临时开启（重启失效）
SET GLOBAL slow_query_log = 'ON';

建议长期开启，记录执行超过2秒的查询，像这样配置my.cnf：

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2

🔧 五大常见病因及治疗方案

🚑 病例1：索引缺失（SQL裸奔）

-- 典型症状：全表扫描
EXPLAIN SELECT * FROM users WHERE age > 20;
-- 结果中出现"type: ALL"就是警报！

💊 处方：

ALTER TABLE users ADD INDEX idx_age (age);

📌 注意：索引不是越多越好，更新频繁的表要谨慎

🚑 病例2：SQL写法太浪（查询大屠杀）

-- 典型反例
SELECT * FROM orders WHERE DATE(create_time) = '2025-08-01';

💊 优化方案：

-- 改为范围查询
SELECT * FROM orders 
WHERE create_time BETWEEN '2025-08-01 00:00:00' AND '2025-08-01 23:59:59';

🚑 病例3：连接池爆了（春运抢票现场）

SHOW STATUS LIKE 'Threads_connected';
-- 如果接近max_connections就是危险信号

💊 急救措施：

-- 临时扩容
SET GLOBAL max_connections = 500;

长期方案：优化连接池配置（如HikariCP），设置合理的wait_timeout

🚑 病例4：锁等待（数据库版"堵车"）

-- 查看锁情况
SHOW ENGINE INNODB STATUS;
-- 重点关注TRANSACTIONS部分

💊 解决方案：

• 事务要短小精悍，避免长事务
• 合理设置隔离级别
• 死锁检测参数调整：

  innodb_deadlock_detect = ON
  innodb_lock_wait_timeout = 50

🚑 病例5：服务器配置太抠（小马拉大车）

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
-- 建议设置为物理内存的70-80%

💊 配置建议（8GB内存示例）：

innodb_buffer_pool_size = 6G
innodb_log_file_size = 512M
query_cache_size = 0  # MySQL8.0已移除

🛠️ 高级排查工具包

Performance Schema（核磁共振）

-- 查看哪些SQL消耗最多CPU
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;

sys schema（智能诊断仪）

-- 查看最耗资源的SQL
SELECT * FROM sys.statement_analysis 
ORDER BY avg_latency DESC LIMIT 5;

pt-query-digest（慢查询分析专家）

# 分析慢查询日志
pt-query-digest /var/log/mysql/mysql-slow.log

输出示例：

# Profile
# Rank Query ID           Response time Calls R/Call 
# ==== ================== ============= ===== ======
#    1 0xABCDEF123456     12.4818 68.2%   100 0.1248

💡 防患于未然的5个习惯

1. 定期体检：每周检查慢查询日志
2. 索引保健：每月用pt-index-usage分析索引使用情况
3. 配置调优：根据业务特点调整InnoDB参数
4. 监控预警：设置CPU超过80%自动报警
5. SQL审查：新SQL上线前必须EXPLAIN检查

🌟 终极心法

遇到CPU 100%别慌张,记住这个排查口诀：

一查进程二看锁，三验索引四观络，
慢查日志必开启，参数调优要灵活。

只要按照这个流程走，保证你能从"救火队员"升级为"预防医学专家"！下次再遇到数据库飙车，记得稳住方向盘哦~ 🚗💨