前提假设（如果有出入你再说）：

• WordPress 内容型站点（taxonomy / 分类较多）
• MySQL 5.7
• 内存 ≈ 4GB（3.6GB 实际可用）
• 单机 MySQL（无主从）
• 表已切换为 InnoDB
• 当前主要问题：高并发聚合查询、CPU 飙高

我按 内存 → InnoDB → SQL → WordPress 表结构 → 运维习惯 五个层级给你一套“可直接落地”的完整调优方案。

 

一、MySQL 5.7 核心内存参数（这是性能地基）

1️⃣ InnoDB Buffer Pool（最关键）

说明：

• 占用约 55%–60% 内存，安全
• taxonomy + posts 索引能常驻内存
• CPU 会明显下降

如果你服务器上除了 MySQL 还有 PHP / nginx，这个值不要再大。

2️⃣ InnoDB Log Buffer

避免频繁 flush，小站完全够。

3️⃣ 临时表内存（很重要）

你的 SQL 有子查询 / IN / JOIN：

防止频繁落盘（这是 CPU 杀手之一）。

 

二、InnoDB 行为与稳定性参数（别忽略）

4️⃣ 关闭不必要的 fsync 压力

innodb_flush_log_at_trx_commit = 2

说明：

• WordPress 可接受 1 秒内事务丢失
• 性能提升非常明显

5️⃣ I/O 模式（SSD 必设）

innodb_flush_method = O_DIRECT

防止 double buffering。

6️⃣ 文件与并发控制

让 InnoDB 自适应调度。

 

三、MySQL 查询与连接层参数（防止被“拖死”）

7️⃣ 连接数（不要盲目开大）

max_connections = 120

说明：

• WordPress + PHP-FPM 足够
• 防止瞬间并发把内存吃光

8️⃣ 超时回收（很关键）

wait_timeout = 60
interactive_timeout = 60

避免“僵尸连接”。

9️⃣ 禁用 Query Cache（5.7 默认就该关）

 

四、必须加的 WordPress 核心索引（你这个站点的重点）

这是你这次事故的核心解法。

wp_posts

wp_term_relationships

wp_term_taxonomy

wp_postmeta（很多站点忽略）

 

五、WordPress 层面的“防 SQL 复发”设置（非常重要）

1️⃣ 禁止实时 last_modified 计算

• 分类 / 标签页
• schema / sitemap
• REST API

👉 能缓存就缓存，不要动态算

2️⃣ REST API 控制（强烈建议）

在 nginx：

location ~* ^/wp-json/wp/v2/(categories|tags|taxonomies) {
limit_req zone=api_limit burst=10 nodelay;
}

3️⃣ WP-Cron 改系统 cron

*/5 * * * * php /path/to/wp-cron.php > /dev/null 2>&1

并在 wp-config.php：

 

六、维护与监控（让你以后不再“突然炸”）

1️⃣ 慢查询日志（常开）

 

slow_query_log = 1
long_query_time = 0.5
log_queries_not_using_indexes = 1

 

2️⃣ 定期表整理（每月）

3️⃣ 清理 WordPress 垃圾

• revisions
• trashed posts
• action_scheduler_logs
• 旧 SEO cache 表

 

七、一份“可直接用”的 my.cnf 示例（整合版）