真正孤立的标签需三表联查：wp_terms、wp_term_taxonomy（taxonomy='post_tag'）和wp_term_relationships，以tr.object_id IS NULL为准；删除须按关系→分类项→术语顺序执行，并清空对象缓存。
WordPress 标签表里哪些 term_id 真的没人用？
直接查 wp_terms 和 wp_term_taxonomy 不够——wp_term_taxonomy 里 taxonomy = 'post_tag' 的记录可能还挂着，但其实没有任何文章通过 wp_term_relationships 关联它。真正“孤立”的标签，得三张表连起来筛。
常见错误是只删 wp_terms 里没出现在 wp_term_taxonomy 的项，结果漏掉大量“有 taxonomy 记录但无 relationship”的死标签。
实操建议：
- 先确认你的前缀是
wp_（如果不是，把下面所有wp_替成你实际的前缀） - 用这个 SQL 找出纯孤儿标签：
SELECT t.term_id, t.name, tt.count FROM wp_terms t INNER JOIN wp_term_taxonomy tt ON t.term_id = tt.term_id AND tt.taxonomy = 'post_tag' LEFT JOIN wp_term_relationships tr ON tt.term_id = tr.term_taxonomy_id WHERE tr.object_id IS NULL;
-
tt.count为 0 是强信号，但不能全信——有些插件或手动操作会让count滞后，必须以tr.object_id IS NULL为准
删之前为什么一定要先清空 wp_term_relationships 关联缓存？
WordPress 的 get_terms()、wp_get_post_tags() 这些函数默认走对象缓存（Object Cache），即使你物理删了数据库里的标签，缓存里还存着旧的 term_taxonomy_id → post_id 映射，前端可能仍显示已删标签，后台批量编辑时也可能报错“term not found”。
这不是数据库问题，是 WP 自己缓存没刷新导致的假残留。
实操建议：
- 执行完 DELETE 后，立刻在 WP-CLI 中运行：
wp cache flush - 如果没装 WP-CLI，进后台 → “工具” → “站点健康” → “信息” → “服务器” 页面底部点“清除所有缓存”（仅限 WP 5.6+ 内置缓存；若用 Redis/Memcached，需单独清）
- 别跳过这步：否则你会反复看到“刚删的标签又冒出来了”，误以为 SQL 没生效
DELETE 语句顺序错了会锁表或失败
WordPress 的外键约束（如果你的 MySQL 引擎是 InnoDB 且启用了外键）会让直接删 wp_terms 报错，因为 wp_term_taxonomy.term_id 是外键。就算没开外键，乱序删除也会触发 wp_term_relationships 的级联失效风险。
中文敏感词/违禁词检测与内容合规性检查工具。支持对小红书（Xiaohongshu）、Douyin（抖音）、WeChat（微信）、Weibo（微博）、Bilibili（哔哩哔哩）、Zhihu（知乎）、Taobao（淘宝）、JD.com（京东）等主流平台的禁用词、限用词及高风险词进行文本扫描与合规性分析。
必须严格按依赖链反向删：先断关系，再删分类项，最后清理术语本身。
实操建议：
- 分三步跑（顺序不能换）：
DELETE tr FROM wp_term_relationships tr INNER JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_id WHERE tt.taxonomy = 'post_tag' AND tt.term_id IN (/* 上一步查出的 term_id 列表 */);
- 再删分类项：
DELETE tt FROM wp_term_taxonomy tt WHERE tt.taxonomy = 'post_tag' AND tt.term_id IN (/* 同上列表 */);
- 最后删术语：
DELETE t FROM wp_terms t WHERE t.term_id IN (/* 同上列表 */);
- 每步都加
WHERE条件，别用TRUNCATE——它不走事务、无法回滚、会重置自增 ID
插件和 REST API 调用可能绕过常规标签计数逻辑
有些 SEO 插件（如 Yoast）或 Headless 前端会直接读 wp_posts.post_content 提取关键词生成标签，不走 wp_set_post_tags()，这类标签不会出现在 wp_term_relationships 里，但会被插件自己维护在元字段或独立表中。它们不是数据库意义上的“孤立标签”，但对你来说仍是无效噪音。
这类标签不会被上面的 SQL 找到，也不能用标准方式删——硬删可能让插件报错或丢失配置。
实操建议：
- 检查是否有活跃插件注册了自定义标签逻辑：
wp plugin list --status=active --field=name | xargs -I{} wp plugin get {} --format=json | grep -i tag - 禁用可疑插件后，再跑一遍前面的三表查询——如果某批标签突然“复活”（即从孤儿变非孤儿），基本就是它在背后维护
- REST API 的
/wp/v2/tags接口默认只返回count > 0的项，但某些主题用get_terms(['hide_empty' => false])会把这类“幽灵标签”拉出来，前端显示为空但链接可访问——这是最隐蔽的坑
事情说清了就结束
