直接删冗余数据比优化表更能显著降体积，真正缩水靠清理revision、auto-draft等僵尸记录；wp_posts和wp_postmeta通常占数据库70%以上，需优先清理并执行OPTIMIZE TABLE回收空间。
直接删掉冗余数据比“优化表”更能显著降低数据库体积。 optimize table 只能整理碎片、回收空闲空间，但不会删除任何一行真实数据；真正让体积缩水的，是清理修订版、自动草稿、垃圾评论这些常年堆积的“僵尸记录”。
哪些表占体积最多？先盯紧 wp_posts 和 wp_postmeta
这两个表通常占整个 WordPress 数据库体积的 70% 以上。原因很实在：wp_posts 里存着所有文章、页面、修订版、附件、菜单项；wp_postmeta 则为每条 post 存一堆元数据——哪怕是一次编辑锁（_edit_lock）、一个自定义字段，都算一行。长期不用的插件残留元数据也全堆在这儿。
- 用 phpMyAdmin 打开数据库后，按“行数”列排序，一眼就能看出哪几张表最“胖”
-
wp_posts行数远超你实际发布的文章数？大概率是修订版和自动草稿在撑场面 -
wp_postmeta行数是wp_posts的 3 倍以上？说明存在大量孤立或过期元数据
手动清理必须执行的几条 DELETE 语句
在 phpMyAdmin 的“SQL”标签页里逐条运行，别图快一次性粘贴全部——出错时方便定位。每条执行完检查受影响行数，确认无误再下一条。
-
DELETE FROM wp_posts WHERE post_type = 'revision';—— 修订版通常占wp_posts半壁江山 -
DELETE FROM wp_posts WHERE post_status = 'auto-draft';—— 自动草稿几乎从不被人工清理 -
DELETE FROM wp_comments WHERE comment_approved = 'spam';—— 垃圾评论增长极快，且极少有人主动清 -
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';—— 过期瞬态数据不释放，越积越多 -
DELETE FROM wp_postmeta WHERE meta_key IN ('_edit_lock', '_edit_last');—— 这俩字段纯属后台编辑临时标记，无业务价值
OPTIMIZE TABLE 不是万能的，但清理后必须做
DELETE 操作只是把行标记为“可复用”，物理空间并不会立刻返还。这时候 OPTIMIZE TABLE 才起作用：重建表、压缩数据页、更新索引统计信息。它不能帮你删数据，但能让删完后的空间真正“瘦下来”。
- 不要对所有表一起
OPTIMIZE，尤其当wp_posts超过 10 万行时，单表执行更稳 - 如果某张表执行
OPTIMIZE后显示OK但 “Overhead” 仍大于 0，说明还有碎片，可重试一次 - InnoDB 表的
OPTIMIZE实际上是ALTER TABLE ... FORCE，会锁表，建议在低峰期操作 - 看到错误
#1025 - Error on rename...？通常是磁盘空间不足或临时目录不可写，不是 SQL 本身问题
真正容易被忽略的是：清理完不检查 wp_postmeta 是否还存在大量孤立记录。比如删光了 wp_posts 里的文章，但对应 post_id 的元数据还在——这种“幽灵数据”得靠 DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts); 清理，但这条语句执行慢、风险高，务必先备份、再小批量测试。
立即学习“PHP免费学习笔记（深入）”；
