一篇从"发文章就 504"到"任意崩溃都能定位"的随身手册。 上半部分是一次真实案例复盘（根因：wp_options 里 17MB 的 cron 被标 autoload）； 下半部分是通用排查决策树，覆盖 WordPress 崩溃的常见大类，遇到别的站崩了也能照着走。

一、真实案例复盘：发文章整站 504

1.1 现象

• 发一篇文章，网站直接崩溃；昨天崩过一次后来自己好了，今天发又崩。

• 加索引、重启服务器都"一点反应没有"。

• 前后台都打不开，浏览器报 504 Gateway Timeout。

• 终端 top：load average 18+、CPU 90%+，mysqld 和一堆 php-fpm 把资源吃满。

504 的含义：Nginx 等上游 PHP 返回，等超时了。说明有请求长时间不结束，PHP-FPM 进程被一个个占住，后续请求全排队超时——连后台都进不去。

1.2 排查误区（关键转折）

逐一验证，都被推翻：

为什么禁用插件、换主题都没用？

因为问题源头在数据库层（wp_options），不在运行中的 PHP 代码。

插件禁用后，它留在数据库里的数据不会消失；

WordPress 每次请求仍会读这些 autoload 配置项，照样被拖死。

经验：当"禁用所有插件 + 切换默认主题"后依然高负载，立刻转向查 wp_options 的 autoload 大项、慢查询、锁、外部流量，别再在插件/主题上打转。

1.3 真凶定位

在宝塔终端（数据库用户 jiupaiming_com）逐条查：

结果一针见血：

机制：cron 是 WordPress 核心存"所有定时任务"的选项（不是任何插件的私有表）。很久前卸载的 qqworld 采集插件，注册的定时采集任务没被清理干净，任务不断堆积把 cron 撑到 17MB；又被标 autoload=on，于是每次请求 WordPress 都要把 17MB 读出、反序列化，mysqld/php-fpm 被打满 → 发文章/访问必 504。这跟"发文章触发"无关，只要有人访问就崩。

1.4 止血修复

phpMyAdmin 执行 SQL 前务必先在左侧点选数据库（否则报 #1046 No database selected）；不想点选就把表名写成 库名.wp_options。

执行后重启 PHP-FPM，再验证：

验证前 cron 17MB 排第一，验证后应只剩几 KB 的正常配置，负载回落、前后台恢复。

1.5 恢复网站

根因已除，把排查时的临时操作还原：

1. 删除空文件夹 wp-content/plugins，把 plugins_bak 重命名回 plugins；

1. 把 wp-content/themes/justnews_bak 重命名回 justnews；

1. 重启 PHP-FPM 与 Nginx；

1. 发一篇测试文章压一压，确认不再 504。

1.6 附：wp_postmeta 索引优化（次要但建议做）

本次还顺手给"热门文章按浏览量排序"的慢查询建了索引，能提升访问速度，建议保留：

仅加索引只能把"全表扫 16 万行"变成"过滤后排序"，不够彻底；要根治热门文章卡慢，还需给查询加 FORCE INDEX + 缓存（Transient 缓存 1 小时），或把浏览量迁到独立表。

（发句牢骚可不可以）

二、通用排查决策树（任意 WordPress 崩溃都能用）

上面的 case 只是"数据库层 autoload 膨胀"这一类。WordPress 崩溃原因很多，先判断症状，再走对应分支，别一上来就盲操作。

入口：先看系统资源（必做）

不管什么症状，先 top（或宝塔首页）看四项：

• 磁盘 100% → 直接跳到【分支 A：磁盘】

• 内存吃满 / 频繁 OOM → 跳到【分支 B：内存】

• CPU 高但磁盘内存正常 → 走【分支 C：代码/数据库】

• 资源都正常但就是 504/白屏 → 走【分支 D：配置/外部】

分支 A：磁盘写满

症状：任何操作都 500/504，MySQL 可能起不来。排查：

修复：

• 清宝塔/nginx 访问日志、慢日志；

• 清 /tmp、WordPress 上传目录里的大文件；

• 删旧的数据库备份 .sql。预防：装日志切割（logrotate），备份别堆在本地。

分支 B：内存不足 / OOM

症状：top 里内存 90%+，PHP 进程频繁被系统杀掉，网站时好时坏。排查：

修复：

• 宝塔 → 软件商店 → PHP → 设置 → 调整 memory_limit（常见 256M~512M）；

• 调小 pm.max_children（PHP-FPM 进程数），避免进程太多把内存吃爆；

• 关掉吃内存却没用的插件（页面缓存、对象缓存配置不当反而更吃）。预防：小内存机器（≤2G）别堆太多插件，开 OPcache 省 CPU。

分支 C：CPU 高，问题在代码/数据库

这是最常见、也最容易被误判的一类。按"隔离法"走：

Step 1：救急重启宝塔重启 PHP → MySQL → Nginx，先让网站能响应。

Step 2：隔离插件

• 宝塔文件管理：把 wp-content/plugins 重命名为 plugins_bak，新建空 plugins；

• 打开前台、发文章测试。

• 还崩 → 走 Step 3。

• 不崩了 → 坐实是插件。把 plugins_bak 里的插件逐个移回 plugins，每移一个测一次，谁触发崩溃谁就是元凶（高发：热门文章、浏览统计、采集、自动发布、CDN 刷新类）。

Step 3：隔离主题

• 放进/保留一个默认主题（twentytwentyfour），把正在用的主题重命名；

• 不崩 → 主题自带的热门文章/相关文章/统计查询有性能问题，按 1.6 给它加缓存；

• 还崩 → 走 Step 4（数据库层）。

Step 4：数据库层（本文案例所在层）

• 查 wp_options autoload 大项（见 1.3），cron 超过几百 KB 就警惕，前两名超 1MB 必处理；

• 查慢日志 / SHOW FULL PROCESSLIST，看有没有 Sending data / Copying to tmp table / Sorting result 的卡死查询；

• 必要时给肥表（wp_postmeta、wp_options、wp_comments）加索引或迁独立表；

• 表损坏：REPAIR TABLE wp_xxx;（MyISAM 直接修；InnoDB 一般靠重启自恢复，严重则要从备份恢复）。

分支 D：资源正常，但发文章/访问就 504 或白屏

这类往往不是资源，而是"单个请求卡住"。

D1：只在发文章时崩，看页面正常说明卡在 save_post 这类发布钩子，大概率是插件发文章时去调外部服务挂起（CDN 刷新、搜索引擎提交、社交平台自动发布、采集回调）。

• 开 WP_DEBUG（见下）复现，看 debug.log 卡在哪一行；

• 临时禁用"自动发布/SEO 推送/CDN 刷新"类插件验证；

• 让外部调用加超时（wp_remote_get 加 timeout => 5），别让它无限等。

D2：看页面也慢/崩，但资源正常

• 开调试看是不是某个外部 API（字体、统计、地图）拖慢首屏；

• 查对象缓存（Redis/Memcached）是否配置错误反而拖慢——配置不对就先关掉。

D3：流量突增导致崩

• 看访问日志是否出现单一 IP 狂刷 / 爬虫暴增；

• 宝塔 → 网站 → 设置 → 开启访问限制 / CC 防护；

• 上 CDN 扛量。

通用前置动作：开调试拿铁证

任何分支定位前，先开调试日志，避免盲猜：

编辑 wp-config.php：

复现崩溃后看 wp-content/debug.log 和宝塔 error.log，报错会直接指向上帝视角的元凶。

三、防崩巡检清单（季度做一次）

其他习惯：

• 卸载采集/推送类插件后，记得查 cron 有没有被它撑大；

• 小内存机器控制插件数量，开 OPcache；

• 备份别堆在网站目录，用对象存储或离线保存；

• 宝塔开"监控"，负载异常能收到告警。

四、一句话总结

WordPress 崩溃，先看资源（磁盘/内存/CPU），再看隔离（插件→主题→数据库），最后看单请求（外部 API/超时）。 本文 case 的真凶——wp_options.cron 被标 autoload 且膨胀到 17MB——是"禁用插件+换默认主题仍无效"时的首要怀疑对象，但绝非唯一原因。按决策树分流，才能对症下药。

操作 SQL / 改配置前，请务必先备份数据库与文件。