WordPress 数据库为什么越来越大？修订版本、Transient 与日志表清理方法

WordPress 数据库变大，并不等于网站已经“出故障”。文章增多、订单累积、评论增加，数据库自然会增长。真正需要处理的，是短时间内异常膨胀、已经失去用途的数据，以及每次请求都会加载的大体积配置。

清理前最容易犯的错误，是看到数据库大就直接执行一段网上找来的 DELETE 语句。数据库里既有 WordPress 核心数据，也有插件自建表和业务记录。先确认是哪张表增长、由谁创建、删除后如何恢复，再动手，通常比“先清了再说”更省时间。

先确认：变大的是数据库，还是磁盘占用

主机面板里的“网站占用空间”通常不只包含数据库，还可能包含：

• wp-content/uploads 中的图片、视频和文档；
• 备份插件生成的压缩包或 SQL 文件；
• 页面缓存、对象缓存落盘文件；
• 调试日志、访问日志、错误日志；
• 暂存目录和升级残留文件。

因此，先分别查看数据库大小和网站目录大小。数据库只有几百 MB，而备份目录占了几十 GB 时，清理数据库不会解决磁盘告警。

第一步：先备份，再找出最大的表

如果服务器已经安装 WP-CLI，可在 WordPress 根目录先导出数据库：

wp db export before-database-cleanup-20260929.sql

导出后确认 SQL 文件确实存在、大小不是 0，并把它复制到网站目录之外或对象存储中。仅在原服务器保留一份备份，遇到磁盘故障或误删时并不可靠。

接着查看各表大小：

wp db size --tables --orderby=size --order=desc

没有 WP-CLI 时，可以在 phpMyAdmin、Adminer 或 MySQL 客户端执行只读查询：

SELECT
  table_name,
  ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC;

记录清理前的数据库总大小、前十张大表、网站首页响应和后台关键功能。后面验证时需要这些基线。

本文示例使用 wp_ 作为表前缀，实际网站可能是其他前缀，可通过 wp db prefix 或 wp-config.php 中的 $table_prefix 确认。

修订版本：为什么 wp_posts 会不断增长

WordPress 每次保存草稿或更新已发布文章时，都可能生成修订版本。修订版本保存在 posts 表中，post_type 为 revision；自动保存也属于特殊修订版本。它们的作用是让编辑者比较差异和恢复旧内容，不是无用垃圾。

先统计各类记录数量：

SELECT post_type, post_status, COUNT(*) AS rows_count
FROM wp_posts
GROUP BY post_type, post_status
ORDER BY rows_count DESC;

如果 revision 数量远高于正式文章，通常是长期频繁编辑、页面构建器反复保存，或从未设置保留上限。可以在 wp-config.php 中限制以后每篇内容保留的修订数：

define('WP_POST_REVISIONS', 10);

这个设置只约束后续保存，不会自动删除历史修订。也不建议为了省空间直接关闭全部修订，因为站点失去内容回滚能力后，一次误编辑的损失可能远高于节省的空间。

处理既有修订版本时，应先确定保留策略，例如“每篇保留最近 10 个”，再使用明确支持按数量保留的维护工具，或通过 WordPress 核心 API 编写一次性脚本。不要只删除 wp_posts 中的 revision 行而忽略关联元数据，更不要在没有备份的情况下复制陌生 SQL 批量执行。

Transient：只清过期项，不要把缓存机制一锅端

Transient 是 WordPress 的临时缓存接口。未配置 Redis、Memcached 等持久对象缓存时，单站点的 Transient 通常保存在 wp_options 表；启用持久对象缓存后，它们可能根本不在数据库里。

过期 Transient 可以安全地重新生成，但“尚未过期”和“已过期”不是一回事。优先使用 WP-CLI 只删除过期项：

wp transient delete --expired

多站点环境还要区分站点级和网络级 Transient。不要把 --all 当作日常清理命令，也不要直接按 _transient_% 模糊匹配全部删除。一次性清空仍在使用的缓存，可能造成短时间缓存击穿、第三方 API 请求激增，甚至触发接口限流。

如果过期 Transient 很快再次堆积，应继续检查 WP-Cron 是否正常、哪个插件在写入大量缓存、插件是否正确设置过期时间，而不是反复手工清空。

wp_options 很大时，重点检查 autoload

wp_options 不只保存站点名称和固定链接，也可能包含插件设置、缓存、队列状态和大段序列化数据。真正影响前台性能的，往往不是表的总大小，而是每次请求都会自动加载的选项总量。

新版 WordPress 的 autoload 字段已经不应只按 yes/no 理解。WordPress 6.6 起还会使用 on、off、auto、auto-on、auto-off 等值，旧值仍兼容。因此，直接写死 WHERE autoload = 'yes' 的旧查询可能漏掉应统计的数据。

可以先在“工具 → 站点健康”中查看自动加载选项提示，再结合数据库工具找出体积最大的选项。不要看到某项很大就直接删除或改成不自动加载：主题配置、路由规则和关键插件设置可能依赖它。正确顺序是确认选项归属、确认是否仍被使用、在测试环境验证，再通过插件提供的设置或 WordPress Options API 调整。

尤其要警惕把日志、完整 API 响应或不断增长的数组写入 autoload 选项。它们会在大量请求中被反复读取，问题不只是占空间，还会增加内存和反序列化开销。

插件日志和任务队列：先认出表，再谈删除

很多数据库膨胀并不来自核心表，而来自插件自建表。常见来源包括：

• wp_actionscheduler_*：WooCommerce 和许多插件使用的后台任务队列；
• 安全插件的访问、拦截、扫描和审计日志；
• 统计分析、访问热图、搜索记录；
• SMTP 或邮件发送日志；
• 失效链接扫描、SEO 爬取记录；
• 电商会话、订单、Webhook 和同步任务记录。

看到陌生表名时，先搜索插件代码或插件文档，确认创建者。若插件已停用，也要判断数据是否仍需留作审计、订单追溯或重新启用。仅凭表名前缀猜测并直接 DROP TABLE，风险很高。

Action Scheduler 会记录任务及执行日志，并自动清理一部分较旧的完成或取消任务。如果 wp_actionscheduler_actions、wp_actionscheduler_logs 很大，先在后台检查是否存在大量 pending 或反复 failed 的任务。积压任务通常意味着计划任务、支付回调、订阅、邮件或外部同步仍有故障；只删记录会把症状暂时藏起来。

在确认业务允许后，可按状态和时间窗口分批清理，而不是一次删除整张表。例如官方 WP-CLI 命令支持：

wp action-scheduler clean --status=complete,canceled --before='90 days ago' --batch-size=50

失败任务应先查明原因并保留必要日志。涉及订单、订阅和支付的网站，还要先与业务负责人确认审计保留期。

孤立元数据和评论数据，要按关联关系检查

插件卸载不完整、文章被外部脚本删除，可能留下孤立的 postmeta、commentmeta 或 term 关系记录。但“没有对应父记录”只是诊断线索，不代表可以立即删除。

先在备份或测试库中统计孤立记录，抽样查看 meta_key 和来源插件，再决定是否处理。大型网站应分批执行并观察锁等待，避免一条大 SQL 长时间锁表。对于 WooCommerce 等已使用自定义订单表的站点，还要确认数据模型和兼容模式，不能套用旧教程中的清理语句。

清理完成后再优化表

删除大量记录后，数据库文件不一定立刻缩小。确认清理结果正确后，再在维护窗口执行：

wp db optimize

该命令会调用数据库工具优化表。大表优化可能占用额外磁盘空间、产生锁等待或增加 I/O，不应在访问高峰盲目执行。托管数据库或主从架构还要遵循服务商的维护建议。

优化结束后，再次运行：

wp db size --tables --orderby=size --order=desc

不要只看数字是否变小，还要验证：

• 首页、文章页、搜索和登录是否正常；
• 后台编辑、媒体上传和定时任务是否正常；
• 商城下单、支付回调、邮件和 Webhook 是否正常；
• PHP 错误日志、数据库慢查询和队列失败数是否异常；
• 对象缓存命中和页面响应是否恢复稳定。

防止数据库再次失控

一次清理只能解决存量问题。更重要的是建立可重复的维护规则：

1. 为修订版本设置合理上限，不完全关闭恢复能力。
2. 为安全、邮件、统计和调试日志设置明确保留天数。
3. 监控 WP-Cron 与 Action Scheduler 的待处理、失败任务数量。
4. 每月记录数据库总大小和前十张大表，观察增长趋势。
5. 定期检查站点健康中的自动加载选项提示。
6. 插件下线前确认其数据是否需要导出，以及卸载程序是否会清表。
7. 把数据库备份放在网站服务器之外，并定期验证可恢复性。

数据库维护的核心不是“删得多”，而是知道每一类数据为什么存在、删掉后怎样恢复。先定位增长来源，再按修订版本、过期 Transient、自动加载选项、日志和任务队列分别处理，通常能在不破坏业务的前提下把数据库控制在合理范围。

参考资料

• WordPress 官方文档：Revisions
• WordPress Developer Resources：Editing wp-config.php
• WordPress Developer Resources：Transients API
• WP-CLI：wp db export、wp db size、wp db optimize、wp transient delete
• Make WordPress Core：Options API autoload changes in WordPress 6.6
• Action Scheduler 官方文档：任务保留与 WP-CLI 清理命令

以上资料于 2026 年 9 月 29 日核验。执行数据库清理前，请结合当前 WordPress、插件和数据库版本再次确认命令适用性。