WordPress默认的自动保存和修订版本功能会生成大量auto-draft与revision记录，长期积累导致wp_posts表臃肿、查询变慢、备份膨胀；应通过直连数据库删除并添加post_type+post_status复合索引优化性能。
wp_posts 表里一堆 auto-draft 和 revision 是谁干的
wordpress 默认开启自动保存和修订版本，每次编辑文章、甚至点开编辑页没改就关掉，都会在 wp_posts 表里塞一条 auto-draft 或 revision 记录。长期不用清理，一张表几万行很常见——查询变慢、备份膨胀、迁移卡顿，都是它拖的。
这些记录本身不展示、不索引、不参与前台逻辑，纯属后台冗余数据。
-
auto-draft：用户点“新建文章”但没保存就离开，留下的空壳 -
revision：每次点击“更新”或自动保存生成的历史快照（默认不限数量） - 它们都占
post_status字段，且post_type分别为post/page等主类型 +revision或auto-draft
直接 SQL 清理最稳，但必须绕开 WordPress 的钩子陷阱
别用插件一键清或 WP-CLI 的 wp post delete 命令批量删 revision——它们会触发 delete_post 钩子，可能激活主题/插件里的清理回调，反而写入新日志、发通知、甚至误删关联附件。
生产环境优先走数据库直删，绕过 PHP 层所有逻辑：
- 先备份：
mysqldump -u user -p dbname wp_posts > wp_posts_backup.sql - 删
auto-draft：DELETE FROM wp_posts WHERE post_status = 'auto-draft'; - 删
revision：DELETE FROM wp_posts WHERE post_type = 'revision'; - 执行后记得
OPTIMIZE TABLE wp_posts;释放磁盘空间（InnoDB 下尤其必要）
注意：MySQL 8.0+ 默认禁用 sql_safe_updates，如果报错“safe update mode”，加条件 AND ID > 0 即可绕过，比如：DELETE FROM wp_posts WHERE post_type = 'revision' AND ID > 0;
想长期控量？关修订版不如限数量，关自动保存要权衡体验
全关 WP_POST_REVISIONS 或 AUTOSAVE_INTERVAL 不现实——编辑中途崩溃丢内容，用户会骂你。
- 限制修订版数量：在
wp-config.php加define('WP_POST_REVISIONS', 3);，只留最近 3 条 - 延长自动保存间隔：加
define('AUTOSAVE_INTERVAL', 120);（单位秒），别设成 0 - 禁用某类文章修订：用
remove_action('pre_post_update', 'wp_save_post_revision');钩子，但仅对特定post_type有效，且得写在插件或主题functions.php里
这些配置只影响后续新增，已有的 revision 还得手动清。
wp_posts 胖了不等于网站慢，但胖得离谱时索引会失效
wp_posts 表超过 5 万行后，如果 post_status 和 post_type 没复合索引，后台文章列表页 WP_Query 查 publish 状态就会扫全表——页面加载从 200ms 涨到 3s 很常见。
检查索引是否健康：
- 运行
SHOW INDEX FROM wp_posts WHERE Key_name IN ('type_status_date', 'post_status'); - 如果没有覆盖
post_type+post_status的索引，手动建一个：ALTER TABLE wp_posts ADD INDEX type_status (post_type, post_status); - 这个索引对后台列表、REST API 查询、
get_posts()都有明显加速效果
清理完数据再加索引，比边删边建快得多；但加完别忘 ANALYZE TABLE wp_posts; 更新统计信息。
revision 和 auto-draft 本身不难删，难的是删完发现后台列表还是卡——这时候八成是索引没跟上，或者某个插件在 wp_posts 里塞了自定义 post_type 却没清理逻辑。
