mysql负载升高通常源于单条sql或配置问题，需先用top/htop确认mysqld cpu占用，再通过show processlist定位长时间运行或锁等待查询，结合iostat排查i/o瓶颈，并调整innodb_stats_on_metadata和innodb_thread_concurrency等参数临时优化。
MySQL服务器负载突然升高，八成是某条SQL或某个配置在“偷偷吃资源”，而不是整体容量不够。先别急着加机器或调大内存，得快速定位那个“真凶”。
用 top 和 htop 确认是不是 mysqld 在吃 CPU
执行 top 或 htop，按 P 排序看 CPU 占用。如果 mysqld 进程排第一，且 CPU 持续 >80%，说明问题在 MySQL 内部；如果其他进程（比如 PHP、Java 应用）占高，那得先查应用层有没有死循环或未关闭连接。
- 注意
%CPU是所有核的总和，500% 表示 5 个核跑满，不一定是单线程问题 -
htop可直接看到每个线程（LWP），能发现是否某个连接线程长期占用 CPU - 如果
mysqld占用不高但load average很高，大概率是 I/O 等待（iowait高），不是 CPU 瓶颈
查 SHOW PROCESSLIST 找出卡住的查询
运行 SHOW FULL PROCESSLIST;，重点关注 Time 大于 10 秒、State 是 Sending data、Copying to tmp table、Sorting result 的行——这些状态基本等于“正在干重活”。
-
Info字段就是 SQL 本身，复制出来用EXPLAIN看执行计划 - 大量
Waiting for table metadata lock表示有 DDL（如ALTER TABLE）阻塞了读写，不是慢查询，是锁冲突 - 如果几百个
Sleep连接但Threads_connected很高，可能是应用没正确释放连接，得查连接池配置
临时止血：关掉元数据统计和限制并发
有些操作看似轻量，实则暗中拖垮性能。两个最常被忽略但立竿见影的开关：
- 执行
SET GLOBAL innodb_stats_on_metadata = 0;—— 防止每次查information_schema（比如监控脚本）都触发全表统计，尤其对大表杀伤力极强 - 设
SET GLOBAL innodb_thread_concurrency = 16;（原值为 0 时相当于不限制）—— 控制 InnoDB 内部并发线程数，避免上下文切换爆炸，适合突发负载场景 - 慎用
max_user_connections限流，它会让客户端报错，只在连接数超 600+ 且已影响服务时考虑
别跳过 iostat -x 1 查 I/O 是否拖后腿
CPU 高 ≠ CPU 真忙。很多情况下，mysqld 进程显示高 CPU，实际是在等磁盘响应（await 高、%util 接近 100%）。这时候优化 SQL 或加大 buffer_pool 无效，得看硬件或 IO 调度。
-
await > 20ms（机械盘）或> 5ms（SSD）就值得警惕 -
%util ≥ 95%表示磁盘已饱和，再快的 SQL 也得排队 - 如果
avgqu-sz > 5，说明请求在队列里堆积，不是数据库慢，是磁盘跟不上
真正难处理的不是慢 SQL，而是那些看起来“合理”却高频执行的小查询——它们不进慢日志，但合起来吃掉 70% 的 CPU。所以别只盯着 long_query_time，得结合 performance_schema.events_statements_summary_by_digest 看平均响应时间和执行次数。
