数据库变大不等于所有页面都会同步变慢。文章修订、日志、会话、订单和options属于不同数据，处理方式也不同。先查看哪些表增长、哪些查询变慢，再决定清理对象。
先区分容量与加载成本
文章修订用于恢复编辑历史，主要与内容版本有关。自动加载的选项则可能在常规请求中被载入，其体积和内容会影响运行成本。它们不能用同一条“删除旧数据”规则处理。
先记录数据库总量、各表大小及一段时间内的增长。商城订单可能存放在不同数据结构中，不能假定所有业务都在posts表里，也不能根据表名前缀就认定某表无用。
修订版本如何处理
核对哪些文章修订最多、是否还需要历史版本。调整未来保留数量前，应了解编辑流程及备份要求。限制之后的修订数量，不等同于已清理全部历史记录。
清理应使用理解WordPress关系的工具，并先备份、预览范围。不要随意删除posts或postmeta中的关联行，更不要将自动草稿、修订和正式文章混为一谈。
自动加载项怎么判断
检查体积较大的选项及其所属组件，确认是否仍在使用。选项名称只是线索，不能证明可以删除。某些值虽然大，但仍承载必要配置；某些已停用插件也可能在恢复启用时需要它们。
需要调整autoload行为时，应根据当前WordPress版本及组件逻辑，通过适当API或可靠工具操作。不要机械地把所有自动加载项改为关闭，也不要删除不认识的序列化值。
用性能证据验收
清理前后记录表大小、代表性页面响应和相关慢查询，确认后台设置、编辑内容及业务功能仍正常。数据库文件占用不一定立刻按删除数据量同比下降，因此不能只用主机磁盘数字判断失败。
如果增长来自调试日志、失败任务或重复写入，应该修复产生数据的原因。只做定期清空，往往会让问题反复出现。
是否可以删除所有停用插件的数据？ 先确认不再使用、有可恢复备份且了解卸载行为。停用不等于废弃，数据可能仍是恢复业务所必需。
参考资料
相关问题
本文为通用排查指南，依据所列官方资料整理；菜单名称和行为可能随版本及主机环境变化。配图为AI生成的概念示意，不是实际故障截图。
