不能直接用该语句，因MySQL 5.7+严格模式报错“target table for update in FROM clause”，且会误删草稿、回收站、定时文章等合法post_id对应的元数据，还忽略post_id=0的全局残留记录。
wordpress中孤立的_post_meta记录无法通过phpmyadmin自动识别，必须手动关联校验，否则极易误删正常数据。
为什么不能直接用DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts)？
这条语句看似合理，但实际在MySQL 5.7+默认严格模式下会报错：You can't specify target table 'wp_postmeta' for update in FROM clause。即使绕过语法限制，执行结果也极不可靠——因为wp_posts表可能包含post_status = 'auto-draft'或trash状态的文章，它们仍属合法存在，对应wp_postmeta记录不应被视作“孤立”。
- WordPress允许草稿、定时文章、回收站条目长期存在，其元数据是功能必需
- 插件（如Yoast SEO、ACF）常为尚未发布的文章预存
_yoast_wpseo_*或_acf_*字段 - 某些主题通过
wp_insert_post()创建临时post后未清理，留下残留post_id = 0的元数据（需单独处理）
安全查找孤立wp_postmeta的三步验证法
必须分步确认，不能跳过中间校验：
- 第一步：导出疑似孤立ID（不删除）
SELECT pm.meta_id, pm.post_id, pm.meta_key FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL AND pm.post_id != 0;
- 第二步：人工抽检前20条，用
SELECT * FROM wp_posts WHERE ID = [post_id];确认是否真不存在（注意检查wp_posts是否使用了自定义前缀） - 第三步：对确认无误的ID批量删除，用
DELETE FROM wp_postmeta WHERE meta_id IN (123,456,789);而非按post_id删——避免一次删掉多个键值对时误伤其他文章
特别注意post_id = 0的元数据行
这类记录常见于主题或插件调用add_post_meta(0, ...)失败后残留，它们永远无法关联到任何文章，可直接清理：
- 先统计数量：
SELECT COUNT(*) FROM wp_postmeta WHERE post_id = 0; - 查看典型键名：
SELECT DISTINCT meta_key FROM wp_postmeta WHERE post_id = 0;（常见如_edit_lock、_wp_attached_file等） - 确认无业务依赖后执行：
DELETE FROM wp_postmeta WHERE post_id = 0;
某些缓存插件会在post_id = 0下写入临时数据，删前建议停用相关插件并清空对象缓存。
立即学习“PHP免费学习笔记（深入）”；
执行后必须验证的两个点
删除操作不可逆，收尾时务必验证：
- 检查WordPress后台“文章 → 所有文章”是否加载正常，重点看是否有文章编辑页报
Warning: Invalid argument supplied for foreach()——这通常意味着某插件试图读取已被删的元数据键 - 运行
SELECT COUNT(*) FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL AND pm.post_id != 0;，结果应为0；若仍有返回，说明还有未识别的边缘情况（如多站点子站的wp_2_postmeta表未处理）
真正麻烦的从来不是SQL语句怎么写，而是搞清楚哪条记录“该删”和“不该删”的边界——这个边界藏在你的插件列表、主题代码和历史操作里，不在数据库schema里。
