WordPress 数据库膨胀：清理修订、垃圾数据与 autoload

准备：备份与现状检查

动手前必须留退路。2026 年主流托管面板都支持一键快照，但别只依赖面板，自己导出一份逻辑备份最稳。用 WP-CLI 执行：

wp db export /tmp/backup-$(date +%F).sql --allow-root
wp db size --allow-root
wp option list --autoload=on --format=csv --allow-root | wc -l

第二条看当前库体积，第三条统计 autoload 的 option 行数。同时记录 wp post list --post_type=revision --field=ID | wc -l 的修订数，作为回滚基线。若站点已接入 WordPress 功能定制与优化 类长期维护，可先在预发库演练。

修订版本与自动草稿

WordPress 默认每保存一次就写一条 revision，自动草稿在编辑未发布时堆积。它们同在 wp_posts 表，post_type 为 revision 或 auto-draft。

限制未来写入

在 wp-config.php 加常量，2026 年仍适用：

define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );

这不会清历史数据，只控增量。

清理存量

用 WP-CLI 删全部修订：

wp post delete $(wp post list --post_type=revision --field=ID --allow-root) --force --allow-root
wp post delete $(wp post list --post_type=auto-draft --field=ID --allow-root) --force --allow-root

若修订数万级，CLI 会超时，改用 SQL：

DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_posts WHERE post_type = 'auto-draft';

注意表前缀可能是 wp_ 以外值，用 wp db query 'SELECT * FROM wp_options LIMIT 1' 确认。

残留的 options 与 meta

卸载插件常留 _transient_、widget_、废弃 cron 与主题 mod；文章删了 postmeta 却还在。它们让表变臃肿。

定位孤儿 meta

查无主 meta：

SELECT pm.meta_id FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;

确认后删：

DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;

清 transient 与废 option

2026 年 WP 核心仍用 options 存 transient。过期项：

wp transient delete --expired --allow-root
wp option delete _site_transient_broken_themes --allow-root

废弃 cron：wp cron event list 找出失效钩子，wp cron event delete hook_name。若曾做 WordPress 换域名：搜索替换怎么做才不会把数据搞坏 类操作，更要查遗留序列化 option。

autoload 过大

wp_options 里 autoload='yes' 的行每次请求全载入。超过 800KB 就拖慢全站。

测量与排序

SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;

常见大户：冗余 slider 插件、旧缓存池、巨型 rewrite_rules。

改为非自动加载

对确认非每页必需的项：

UPDATE wp_options SET autoload='no' WHERE option_name IN ('old_plugin_data','huge_cache');

或用 wp option update <key> <value> 重设。改完跑：

SELECT SUM(LENGTH(option_value))/1024 AS autoload_kb FROM wp_options WHERE autoload='yes';

目标压到 800 以下。

实施步骤

1. wp db export 导出全库到非 web 目录
2. 在 wp-config.php 设 WP_POST_REVISIONS 与 AUTOSAVE_INTERVAL
3. 用 WP-CLI 或 SQL 删 revision、auto-draft、孤儿 meta、过期 transient
4. 用 SQL 找出 autoload 大户并 UPDATE 成 no
5. 跑 wp db size 与 autoload 体积 SQL 对比基线
6. 前台后台各点 10 个页面确认无 500 或空白

清理前备份与清理后的效果验证

备份已在上文准备节完成。验证要量化：

指标	工具	达标
库体积	wp db size	降 10%+ 或符合预期
autoload 体积	上文 SUM SQL	< 800KB
修订数	wp post list –post_type=revision	0 或仅留 5 内
TTFB	浏览器网络面板	较清理前下降

若用 WP-CLI 常用命令：把重复的运维动作变成一行命令 里的方式做日常巡检，可把上述 SQL 存成脚本定时比对。

回滚方法

删错数据立刻导回：

wp db import /tmp/backup-2026-xx-xx.sql --allow-root

若只误改 autoload，反向 UPDATE 回 yes 即可。切忌在生产直接跑无 WHERE 的 DELETE。曾有人忘加 post_type 把文章全清，只能靠备份。

常见问题

清理后后台变慢是不是失败了？

不一定。可能刚清完 transient 正在重建。等 5 分钟再测；若持续慢，查 wp_options 是否误改了核心项。

能不能用插件代替命令？

可以，但批量删除仍建议 WP-CLI。插件适合看 autoload 概览，真删大表还是命令行稳。

多久清一次合适？

高活跃站每月一次；普通企业站每季度。配合 WP_POST_REVISIONS 限制增量。

动作清单

• 今天就用 wp db export 导出当前库
• 在 wp-config.php 加入 WP_POST_REVISIONS 限制
• 跑一遍孤儿 meta 与过期 transient 清理
• 把 autoload 压到 800KB 内并记入监控
• 把验证 SQL 存进运维脚本每月跑

需要长期数据库治理？看我们的 定制服务：https://runokwp.com/services/custom-development/ ，更多文章见 https://runokwp.com/tech-articles/ 。

“, “faq”: [{“question”: “清理后后台变慢是不是失败了？”, “answer”: “不一定。可能刚清完 transient 正在重建。等 5 分钟再测；若持续慢，查 wp_options 是否误改了核心项。”}, {“question”: “能不能用插件代替命令？”, “answer”: “可以，但批量删除仍建议 WP-CLI。插件适合看 autoload 概览，真删大表还是命令行稳。”}, {“question”: “多久清一次合适？”, “answer”: “高活跃站每月一次；普通企业站每季度。配合 WP_POST_REVISIONS 限制增量。”}], “cover”: “Flat technical illustration of a database server with stacked data layers, revision papers being shredded, and a shrinking autoload bar, blue and grey palette, no text no logo no watermark

参考资料与延伸阅读

• WordPress 开发者文档
• WordPress 主题开发手册
• WordPress 插件开发手册