兄弟，结合你的情况（8核Xeon E5-2670服务器、12个WordPress站点其中4-5个有流量），MySQL啃掉70%+CPU大概率是低效查询、配置没跟上硬件、站点插件/代码拖后腿这几个原因，咱们一步步来排查：

一、先揪出拖垮CPU的「坏查询」 #

这是最核心的第一步，CPU飙高几乎都是慢查询或者高频低效查询搞的鬼：

• 打开cPanel里的PhpMyAdmin，找到你的数据库，开启「慢查询日志」（要是有服务器权限，直接改my.cnf/my.ini：设置slow_query_log = 1、long_query_time = 2，把执行超过2秒的查询都记下来）
• 看慢查询日志时重点盯这几类：
  • SELECT查询里WHERE/JOIN用到的字段没加索引的
  • 批量更新/删除却没加LIMIT的语句
  • WordPress常见坑：调用wp_postmeta时没索引，或者插件生成的复杂自定义查询
• 也可以直接在PhpMyAdmin的SQL标签执行SHOW PROCESSLIST;，实时看当前在跑的查询，有没有长时间卡在「Query」状态的语句。

二、排查WordPress站点的锅 #

你有12个WP站，很大概率是某几个有流量的站点出问题了：

• 插件排查：把有流量的站点逐个禁用插件，看CPU会不会降。重点查统计插件、缓存插件（配置错了反而会加重查询）、电商类插件（比如WooCommerce的库存/订单查询）、自定义表单插件（攒了大量数据写入）
• 主题与自定义代码：有些主题写的查询巨低效，比如循环调用get_posts不设posts_per_page，或者用$wpdb写没优化的SQL
• 缓存有没有配对：确认WP开了缓存没？比如Redis、Memcached，或者WP Rocket这类页面缓存插件。没缓存的话，每次访问都直接查数据库，高流量下CPU不炸才怪
• 清理数据库冗余：12个站的数据库肯定攒了不少垃圾，比如过期评论、草稿、没用的postmeta数据，用WP-Optimize这类工具清一清，再跑OPTIMIZE TABLE命令优化表

三、给MySQL配置「升级适配」你的服务器 #

你的服务器有8核CPU+14G可用内存，默认的MySQL配置肯定没用到硬件性能：

• 关键参数调整（cPanel里可以用「MySQL Configuration」工具改，或者直接编辑my.cnf）：
  • innodb_buffer_pool_size：设成总内存的50%-70%，你的情况给8G-10G就行，这个是InnoDB缓存数据和索引的地方，调大了能大幅减少磁盘IO，CPU压力直接降下来
  • query_cache_size：MySQL 8.0+已经删了这个参数，5.7及以下可以设64M-128M，但注意如果查询更新频繁，缓存命中率低反而浪费CPU
  • innodb_flush_log_at_trx_commit：要是对数据一致性要求不是极端高，改成2，能减少磁盘写入的CPU开销
  • max_connections：默认150太多了，你的情况设80-100足够，避免太多连接抢CPU
• 检查表引擎：确保所有WP表都用InnoDB（MyISAM早就淘汰了，性能差还容易锁表），用ALTER TABLE table_name ENGINE=InnoDB;转就行

四、服务器层面再扫一遍 #

• 用top命令（cPanel里开「Terminal」就能跑）看是单个MySQL进程占满CPU，还是多个查询并发搞的。如果是单个慢查询，先优化那个；如果是并发高，就得调连接数和缓存
• 你的内存还有14G可用，暂时不用担心内存不够用SWAP拖慢，但要确保MySQL的buffer池设对，别浪费内存
• 看看Process Manager里有没有其他高CPU进程，比如PHP-FPM（要是WP的PHP进程太多，也会和MySQL抢CPU），可以把PHP-FPM的pm.max_children设成20-30，根据CPU核心数来

最后说一句，优先从慢查询日志入手，找到最耗CPU的那个查询，这是最快解决问题的路径——毕竟70%+的CPU占用，肯定是有具体的查询在拖后腿。

内容的提问来源于stack exchange，提问作者Rinalds Ažiņš-Bikars