简短结论：WordPress 站点健康提示”自动加载选项可能会影响性能”，是因为 wp_options 表里自动加载的数据太多。用 phpMyAdmin 查出占空间最大的几项，确认是旧主题或旧插件的残留后，把它们的 autoload 改成 no（不删除数据），再清缓存验证即可。整个过程只改了两行数据，可以随时回退。

环境：WordPress 7.1、MariaDB 10.5、Xserver 共享主机。过程不依赖主机，任何能用 phpMyAdmin 的环境都一样。

现象

在「工具 → 站点健康」里，出现一条 critical：

自动加载选项可能会影响性能。……您站点的选项表中有 990 个自动加载的选项（大小：971 KB）。

这个警告是什么意思

WordPress 在每次加载页面时，会先把 wp_options 表里 autoload 标记为自动加载的选项一次性读进内存。这些数据越大，每个页面都要多读一份，拖慢站点。

这项检查从 WordPress 6.6 开始加入站点健康，默认在自动加载选项总大小达到 800,000 字节时报 critical。站点健康显示的 KB 是按 1024 换算的，800,000 字节约等于 781 KB。所以我的 971 KB 要降到 781 KB 以下，至少减少约 190 KB。

处理思路

1. 先备份。
2. 查出占空间最大的自动加载选项。
3. 判断每一项来自哪里，哪些是残留。
4. 确认没有内容依赖它们。
5. 把它们改成”不自动加载”，不直接删除。
6. 清缓存，复查站点健康和页面。

第一步：备份数据库

用 UpdraftPlus 备份一次数据库，或者在 phpMyAdmin 里导出 wp_options 这张表。下面的操作都可以回退，备份是保险。

第二步：打开 phpMyAdmin，并选中数据库

在主机的控制面板里打开 phpMyAdmin，先点左侧的 WordPress 数据库名（不是 information_schema），再点上方的「SQL」标签。

如果没有先选数据库就运行查询，会看到这个报错：

#1046 – データベースが選択されていません。

意思是”没有选择数据库”，选中数据库后重新运行即可。

第三步：查出最大的自动加载选项

运行下面的查询（只是查看，不修改数据）：

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC
LIMIT 30;

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC
LIMIT 30;

说明：

• wp_ 是默认的表前缀。如果提示表不存在，在左侧展开数据库，找到以 _options 结尾的表，把查询里的 wp_options 换成它。
• WordPress 6.6 起，会自动加载的取值不只有 yes，还可能是 on、auto-on、auto，所以查询里全部列出。

我的结果前几行：

排名第一和第二的两项加起来约 587,000 字节（约 574 KB），占了总量的一多半。其余的都是几十 KB 以下。

第四步：判断每一项能不能动

我的主要两项：extend_builder_theme 和 colibri_page_builder_demo_sites，名字对应的是 Extend Themes 的 Colibri 页面构建器。站点现在用的是 Twenty Twenty-Five，没有启用 Colibri，所以它们看起来是以前用过 Colibri 后留下的。但”看起来是”不够，要先确认没有内容在用。

第五步：确认没有内容依赖它们

用关键词在文章表里搜（可把 colibri、extend-builder 换成你的网站对应的名字）：

SELECT COUNT(*) AS posts_using_keyword
FROM wp_posts
WHERE post_content LIKE '%colibri%' OR post_content LIKE '%extend-builder%';

SELECT COUNT(*) AS posts_using_keyword
FROM wp_posts
WHERE post_content LIKE '%colibri%' OR post_content LIKE '%extend-builder%';

SELECT COUNT(*) AS meta_using_keyword
FROM wp_postmeta
WHERE meta_key LIKE '%colibri%';

SELECT COUNT(*) AS meta_using_keyword
FROM wp_postmeta
WHERE meta_key LIKE '%colibri%';

我的结果是：文章表 69 条，元数据 0 条。再按类型拆开看：

SELECT post_type, post_status, COUNT(*) AS n
FROM wp_posts
WHERE post_content LIKE '%colibri%' OR post_content LIKE '%extend-builder%'
GROUP BY post_type, post_status
ORDER BY n DESC;

SELECT post_type, post_status, COUNT(*) AS n
FROM wp_posts
WHERE post_content LIKE '%colibri%' OR post_content LIKE '%extend-builder%'
GROUP BY post_type, post_status
ORDER BY n DESC;

结果：

69 条里没有一条是 post、page 或 product：59 条是修订版本，剩下 10 条是 extb_post_* 这种构建器自己的模板（header_front_page、main_404、sidebar_post 等）。也就是说，目前的文章、页面、商品都没有用到 Colibri，这些数据只是留在数据库里的模板。

第六步：改成不自动加载（不删除）

在选中数据库的 SQL 页面运行：

UPDATE wp_options
SET autoload = 'no'
WHERE option_name IN ('extend_builder_theme', 'colibri_page_builder_demo_sites');

UPDATE wp_options
SET autoload = 'no'
WHERE option_name IN ('extend_builder_theme', 'colibri_page_builder_demo_sites');

phpMyAdmin 会显示 2 行受影响。

这一步只改了读取方式，没有删除数据：这两项不再随每个页面预加载，只有需要时才读取，数据本身原样保留。no 是合法的取值，WP-CLI 的 wp option set-autoload 也支持 on、off、yes、no。

如果以后发现有问题，改回去即可：

UPDATE wp_options
SET autoload = 'yes'
WHERE option_name IN ('extend_builder_theme', 'colibri_page_builder_demo_sites');

UPDATE wp_options
SET autoload = 'yes'
WHERE option_name IN ('extend_builder_theme', 'colibri_page_builder_demo_sites');

第七步：清缓存并验证

1. 点后台顶部的「删除缓存」（缓存插件的清除按钮）。
2. 刷新「工具 → 站点健康」，这条 critical 不再出现。处理后的自动加载总量是 [处理后的实际大小]，比阈值低得多。
3. 依次打开首页、一篇文章、Lab 页、WooCommerce 页面和后台，确认都正常。

到此站点一切正常，处理到这里就完成了。

为什么改成不自动加载，而不是直接删除

• 可逆：改错了一条语句就能还原，删除不行。
• 没有数据损失：数据还在，需要时随时能读取。
• 同样有效：警告看的是”自动加载的总量”，数据留在表里不计入。

等观察几天确认没问题，再决定要不要彻底删除。不删也没关系，只是占一点数据库空间。

不想写 SQL 的办法

WordPress 性能团队的 Performance Lab 插件，会在站点健康里增加一张自动加载选项的表，可以在后台直接查看和停用不需要的项。可以临时装一下，处理完再删除。

常见问题

运行 SQL 提示 #1046？
没有先选数据库，点左侧的 WordPress 数据库名后再运行。

提示表不存在？
表前缀不是 wp_，在左侧展开数据库，找以 _options 结尾的表，替换查询里的表名。

警告处理后又出现了？
说明还有别的插件在持续写入大选项。再运行第三步的查询，看新的最大项是什么。

查到的最大项是正在使用的插件怎么办？
不要动，也不要删除。可以先看这个插件的设置里有没有清理缓存或日志的选项；如果确实需要降低，只把那一项改成 no，并观察功能是否正常，有问题再改回 yes。

修订版本和构建器的模板要清理吗？
它们没有被自动加载，不影响这个警告。想减小数据库再另外处理。

相关内容

• Lab：WordPress、Python 自动化与自建工具笔记
• WordPress｜文章分类页第二页 404：每页文章数不一致的原因与解决办法