很多站点在反复启停插件之后，数据库体积就会悄悄变大。wp_options 中堆积着失效的配置，wp_postmeta 里留着旧的字段，Cron 表里还有没有回调的定时任务。真正麻烦的不是空间占用，而是自动加载项变多之后，每次页面请求都要顺带读出一堆用不上的内容。
容易踩到的边界就是停用（Deactivate）和卸载（Delete）不是同一个意思。停用阶段只适合清除临时缓存、注销重写规则和失效计划任务，不适合删除用户配置或者自建表；后者应该交给 uninstall.php 或者 register_uninstall_hook，并且用 WP_UNINSTALL_PLUGIN 常量来保护，防止被意外触发。
如果想让清理的动作尽可能自动化，可以按照三层来进行配置：
第一层就是插件自身的收敛。主文件中用 register_deactivation_hook 来清除瞬态和 Cron 钩子，在卸载文件中再进行选项、元数据和自定义表的清理工作。换插件的时候不用人工去翻数据库了。
第二层是定期收尾。使用 WP-CLI 和系统 crontab 来每周运行一次孤立任务清理，比如列出没有回调的 cron 事件然后删除它们，再清除掉过期的 _transient_ 条目。不要在访问高峰期进行，也不要一次性 DROP 来源不明的表。
第三层，加一道隔离。直接删除之前先把可疑表改名前缀隔离，保存三十天之后再删除；选项类数据先导出再删除。即使判断错误归属，也还有退路。
配置的时候要先进行整库备份，去掉核心选项以及还在使用的插件前缀。清除之后查看后台响应和慢查询日志，数值降低才是真的有效果。