WordPress瞬态缓存是通过wp_options表实现的带过期时间的键值对，必须成对删除_transient_XXX及其_timeout_XXX记录；直接清空wp_options会丢失核心配置导致网站异常。
WordPress瞬态缓存是什么，为什么不能直接删 wp_options 表？
瞬态（transient）是 wordpress 用 wp_options 表模拟的带过期时间的键值缓存，本质是临时数据，但和普通 option 不同：它自带 _transient_ 和 _transient_timeout_ 两组键名配对。直接清空 wp_options 会干掉站点标题、主题设置、插件配置等核心数据，网站大概率白屏或后台失联。
常见错误现象：DELETE FROM wp_options WHERE option_name LIKE '_transient_%'; 看似合理，但漏掉了 timeout 记录，残留的 _transient_timeout_ 键会让后续调用 get_transient() 持续尝试清理已不存在的 transient，反而增加数据库查询负担。
- 必须成对删除
_transient_XXX和对应_transient_timeout_XXX - 部分插件（如 WP Rocket）还会写入
_transient_feed_或带前缀的变体，需一并覆盖 - MySQL 5.7+ 支持 JOIN 删除，但低版本只能分两步走，否则报错
安全批量删 transient 的 SQL 写法（兼容 MySQL 5.6+）
最稳妥的做法是先查出所有待删的 transient key 名，再分批执行。不推荐单条大 SQL 一次性扫全表——高流量站可能锁表几秒，用户访问卡顿。
实操建议：
- 登录 phpMyAdmin 或命令行，先运行：
SELECT option_name FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_transient_timeout_%';确认数量（通常几千到几万条） - 若确认要清空，执行两步删除（顺序不能反）：
DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout_%';DELETE FROM wp_options WHERE option_name LIKE '_transient_%'; - 别用
TRUNCATE——它重置自增 ID，可能影响其他 option 插入逻辑
用 WP-CLI 替代 SQL 更省心？注意环境权限和 hook 干扰
WP-CLI 调用 wp transient delete --all 看似干净，但它底层仍会逐条调用 delete_transient()，触发所有已注册的 delete_transient action 钩子。某些缓存插件（如 W3 Total Cache）会在该钩子里同步清理外部 Redis/Memcached，导致瞬时高负载甚至超时。
- 生产环境慎用
--all，优先按前缀删：wp transient delete --prefix='_transient_feed_' --network - 确保 CLI 用户有
manage_options权限，否则返回Sorry, you are not allowed to manage these options. - 如果网站启用了对象缓存（如 APCu），
wp transient命令可能不生效——因为 transient 已被重定向到内存，SQL 删的是“过期副本”
删完 transient 后页面反而变慢？检查是否误伤了关键预热缓存
有些主题或插件会把首页 HTML 片段、菜单结构、API 响应结果存在 transient 里，并设长过期时间（比如 24 小时）。手动清空后，首次访问会触发重建逻辑，CPU 占用飙升，用户感知为“变慢”。这不是 SQL 错了，而是缓存策略没对齐。
- 观察
wp_options中_transient_timeout_值是否普遍 > 0 —— 如果大量是 0，说明这些 transient 是“永不过期”的，删了就真没了 - 用 Query Monitor 插件看首页加载时哪些
get_transient()返回 false，对应代码位置就是重建源头 - 临时方案：删之前导出关键 transient（如
_transient_theme_roots、_transient_block_editor_settings），删完再回填
真正影响速度的从来不是 transient 本身，而是删完后重建它的那个函数跑得多慢。盯住 PHP 执行时间和慢查询日志，比盲目清缓存有用得多。
