必须分类型识别、逐项验证、成对清理数据库冗余数据，否则导致功能异常、计数错乱或后台卡死；需区分真冗余与关键配置，修订版和草稿须三表联删，删评论后须手动更新comment_count，瞬态缓存须成对删除并优化表。
不能靠“一键清空”或盲目删表，必须分类型识别、逐项验证、成对清理，否则删掉的是缓存键却留下 timeout、删掉 postmeta 却误伤 post_id = 0 的全局配置、删完评论却不更新 wp_posts.comment_count，结果网站功能异常、前台计数错乱、后台卡死。
先确认哪些数据真冗余，别把配置当垃圾
WordPress 数据库里很多带“临时”“草稿”“transient”字样的记录，不是都能删。比如：
-
post_id = 0的wp_postmeta记录：很多插件（如多语言、会员系统）用它存站点级配置，删了直接功能失效 -
_transient_apitoken_*这类带业务关键词的选项：可能是插件硬编码的长期 token，不是临时缓存 -
wp_options里以_site_transient_*开头的：多站点环境下属于网络级缓存，单删子站会漏 - 已卸载插件创建的自定义表（如
wp_wpforms_tasks）：表名通常含插件名，删前得确认是否真不用
删修订版和自动草稿要连带关联数据
只删 wp_posts 里的 revision 或 auto-draft 行，会留下孤立的 wp_term_relationships 和 wp_postmeta 记录，下次查文章时可能触发 JOIN 失败或慢查询。
推荐用三表联删语句（替换 wp_ 为你的实际前缀）：
立即学习“PHP免费学习笔记（深入）”；
DELETE a, b, c FROM wp_posts a LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c ON (a.ID = c.post_id) WHERE a.post_type = 'revision' OR a.post_status = 'auto-draft';
执行前务必备份整库；如果担心误删，可先用 SELECT COUNT(*) 统计数量：
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision' OR post_status = 'auto-draft';
删垃圾评论后必须手动修复评论计数
直接 DELETE FROM wp_comments WHERE comment_approved IN ('0', 'spam'); 是最快方式，但 WordPress 不会自动同步更新 wp_posts.comment_count 字段，导致文章列表显示评论数远高于实际可见数。
删完立刻执行：
UPDATE wp_posts p
SET p.comment_count = (
SELECT COUNT(*)
FROM wp_comments c
WHERE c.comment_post_ID = p.ID AND c.comment_approved = '1'
)
WHERE p.ID IN (
SELECT DISTINCT comment_post_ID FROM wp_comments WHERE comment_approved IN ('0', 'spam')
);
这个子查询范围小、效率高，比全表更新安全得多。若站点评论极多，可加 LIMIT 1000 分批跑。
瞬态缓存必须成对删除，且注意多站点差异
删 _transient_feed_mod_ 却不删 _transient_timeout_feed_mod_，下次调用 get_transient() 就会反复尝试重建，引发锁表或超时。
安全写法（支持单站 + 多站点）：
DELETE FROM wp_options WHERE option_name REGEXP '^(_transient_|_transient_timeout_|_site_transient_|_site_transient_timeout_)' AND option_name NOT REGEXP '_transient_(timeout_)?(doing_cron|plugin_update|theme_update)';
最后那个 NOT REGEXP 排除了几个关键运行中状态，避免中断后台更新任务。删完记得在 phpMyAdmin 中对 wp_options 执行 OPTIMIZE TABLE，否则碎片会导致后续查询变慢。
最易被忽略的点：所有清理操作之后，wp_postmeta 和 wp_options 表的索引可能已失效或偏移，不执行 OPTIMIZE TABLE，下一次 SELECT 仍可能走全表扫描——这不是“清理完成”，只是“表面干净”。
