在phpmyadmin中执行select post_type, post_status, count(*) from wp_posts group by post_type, post_status order by count(*) desc，重点关注post_status = 'auto-draft'行的数值；若超500需优化，超2000应立即删除，并确认表前缀、无活跃编辑、无插件依赖后，用delete from wp_posts where post_status = 'auto-draft' and id > 0安全清理，再执行optimize table wp_posts释放空间。
怎么在phpMyAdmin里一眼看出auto-draft太多
直接查 wp_posts 表，执行这句 SQL：
SELECT post_type, post_status, COUNT(*) FROM wp_posts GROUP BY post_type, post_status ORDER BY COUNT(*) DESC;重点关注
post_status = 'auto-draft' 这一行的数值。如果超过 500，基本可以断定是编辑习惯或插件触发异常导致的堆积；超过 2000 就该立刻处理——它会拖慢后台文章列表加载、影响 wp_get_recent_posts() 等查询性能。
删 auto-draft 前必须确认的三件事
别急着点“执行”，先检查以下几点：
- 确认表前缀：默认是
wp_，但很多站点改过（如myblog_），SQL 里的wp_posts要同步替换 - 确认没有活跃的未保存草稿：用户正在编辑页停留时，WordPress 会每 15 秒写一条新的
auto-draft，此时删可能干扰当前操作（概率低但存在） - 检查是否有插件依赖
auto-draft：极少数定制投稿插件会读取该状态做流程判断，删前可在测试环境跑一遍投稿流程
安全删除 auto-draft 的 SQL 写法
用这条语句最稳妥：
DELETE FROM wp_posts WHERE post_status = 'auto-draft' AND ID > 0;加
ID > 0 是为了绕过 MySQL 8.0+ 默认开启的 sql_safe_updates 模式报错。删完务必执行：OPTIMIZE TABLE wp_posts;否则 InnoDB 不会真正释放磁盘空间，
wp_posts 表体积不会变小。
为什么删完又冒出来？重点盯这两个地方
自动草稿不是“删一次就永绝后患”的问题，反复出现通常卡在这两个环节：
-
AUTOSAVE_INTERVAL设得太短：比如设成30秒，用户点开编辑页不动也会每半分钟生成一条；建议设为120或更高，在wp-config.php加define('AUTOSAVE_INTERVAL', 120); - 页面跳转不规范：某些主题或插件在新建文章后用
wp_redirect()跳转但没exit，导致 WordPress 误判为“未完成提交”，留下auto-draft - REST API 批量创建失败：用 WP-CLI 或第三方工具批量发文章时，某条失败但事务没回滚，残留
auto-draft—— 这类需结合wp_options里的_transient_rest_api_request记录交叉排查
真正麻烦的不是删，而是识别哪条 auto-draft 是“该留的”（比如用户刚点新建还没输标题）——它和“该删的”在数据库里长得一模一样，只能靠时间戳和关联的 post_meta 判断，这点容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
