WordPress新闻站MySQL高CPU占用问题排查求助（50万+文章）

阿华AIGC实验室

2026-5-27

解决50万+文章WordPress站点MySQL CPU过高问题

Hey 你好！针对你用EasyEngine+WordPress+Redis搭建的50万+文章新闻站遇到的MySQL（MariaDB）CPU占用过高问题，我仔细看了你的服务器配置和my.cnf文件，下面给你一步步的排查和优化方案：

首先，定位CPU高负载的具体来源

当前你的慢查询日志设置long_query_time = 10，这个阈值太宽松了——对于新闻站点来说，超过1秒的查询就已经会拖慢页面加载、消耗CPU了。咱们先调整慢查询日志配置，精准定位问题：

修改my.cnf里的Logging部分：

slow_query_log = 1
long_query_time = 1
log_queries_not_using_indexes = 1

重启MariaDB后，去/var/log/mysql/mariadb-slow.log里看看哪些查询在搞事情。WordPress站点常见的高负载查询通常来自：

你的my.cnf有几个关键参数可以调整，直接降低CPU消耗：

你现在开了query_cache_size = 256M，但对于新闻这种写频繁的站点，查询缓存反而会成为性能瓶颈——每次发布新文章、更新评论，都要失效一批缓存，反而增加CPU开销。而且你已经用了Redis做页面缓存，MySQL查询缓存的收益几乎可以忽略，直接关掉：

query_cache_type = 0
query_cache_size = 0

InnoDB是你的默认存储引擎，针对SSD和大站点调整：

innodb_log_file_size: 当前是默认的10M（注释掉了），太小了，建议设置为1G（注意：修改前要先停MariaDB，删掉/var/lib/mysql/ib_logfile0和ib_logfile1，再启动服务）
innodb_io_capacity: 你的是SSD，默认的400太低，调到2000，充分发挥SSD的IO性能
innodb_flush_log_at_trx_commit: 如果能接受1秒内的数据丢失风险（新闻站点一般没问题），改成2，减少磁盘IO带来的CPU开销
innodb_buffer_pool_size: 当前15G对于32G内存来说是合理的，不过可以微调至18G（给系统、Redis留够内存）

thread_cache_size = 500: 太大了，你的max_connections才300，线程缓存设为64足够，过大的缓存会占用内存还增加CPU开销
table_open_cache = 600: 对于50万+文章的站点来说偏小，调到4096，减少表频繁打开关闭的开销

光调MySQL还不够，WordPress本身的查询优化才是治本：

确认Redis缓存生效: 用EasyEngine的ee redis status命令检查缓存命中率，确保页面、对象（比如WP_Query结果）都被Redis缓存了，减少MySQL的查询次数
清理冗余数据: 运行wp db optimize优化InnoDB表碎片，用WP-Optimize这类插件清理过期的文章修订版、垃圾评论、过期的 transient 数据
排查低效插件: 很多统计、社交分享类插件会执行大量低效查询，禁用那些你不用的插件，或者替换成轻量版本
优化主题查询: 检查主题的首页、归档页，对于不需要分页的列表，给WP_Query加上'no_found_rows' => true，避免不必要的COUNT(*)查询；如果有posts_per_page设得太大的情况，也适当调小
添加自定义索引: 根据慢查询日志里的无索引查询，手动加复合索引。比如如果频繁按post_date和post_status查询，就执行：
```
ALTER TABLE wp_posts ADD INDEX idx_date_status (post_date, post_status);
```

提高文件描述符限制: 编辑/etc/security/limits.conf，添加：
```
mysql soft nofile 65535
mysql hard nofile 65535
```
然后在my.cnf里加上open-files-limit = 65535，避免MySQL因为文件描述符不足而卡顿
启用内存过度提交: 编辑/etc/sysctl.conf，添加vm.overcommit_memory = 1，防止MySQL被系统的OOM Killer意外杀掉