WP Object Cache默认不存数据库，仅运行时内存缓存；启用Redis/Memcached后需用对应命令或WP-CLI清空，phpMyAdmin无效；误删wp_options中含_cache的option可能破坏插件功能。

Object Cache在数据库里根本没存——别白找wp_options

wordpress的wp object cache默认是运行时内存缓存，不持久化到数据库。除非你装了redis、memcached或apcu这类外部对象缓存后端，否则wp_options表里压根没有“object cache记录”可删。很多人在phpmyadmin里翻遍wp_options找_transient_或_cache_开头的option，结果清了一堆transient却对object cache毫无影响——因为那俩不是一回事。

真用了Redis/Memcached？得去服务端清，不是phpMyAdmin的事

如果你启用了Redis或Memcached作为对象缓存后端（比如通过object-cache.php Drop-in），那缓存数据完全不在MySQL里，而是在Redis实例或Memcached进程内存中。此时：

• phpMyAdmin对它完全不可见，执行任何SQL都无效
• 必须用对应命令行工具：Redis用redis-cli FLUSHALL，Memcached用echo "flush_all" | nc 127.0.0.1 11211
• 若托管环境不开放终端（如多数共享主机），只能通过插件界面或WP-CLI：wp cache flush
• 部分主机控制面板（如cPanel的Redis Manager）提供图形化清空入口，比硬连终端更稳妥

误删wp_options里带_cache的option可能搞坏插件

有些插件（如WP Rocket、Query Monitor）会在wp_options里存自己的缓存配置或诊断数据，名字含_cache但和WP Object Cache无关。例如：

rocket_cache_bypass

query-monitor-cache-stats

这些不是垃圾，删了会导致插件功能异常或统计丢失。判断依据只有一条：autoload = 'yes'且option_name以_transient_或_site_transient_开头的，才是安全可清的临时数据；其余一律不动。

Work Productivity Word Mail Workflow Helper

构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等

下载

真正该在phpMyAdmin里操作的，只有Transients和Orphaned Tags

如果你的目标确实是“手动清理缓存类数据”，且没装外部对象缓存，那实际能动的只有：

• 清除所有Transients：DELETE FROM `wp_options` WHERE `option_name` LIKE '_transient_%' OR `option_name` LIKE '_site_transient_%';
• 清除孤立标签前必做的缓存断联：DELETE FROM `wp_options` WHERE `option_name` = 'wp_object_cache';（仅当存在该option时，它是WP自带文件缓存的残留）
• 优化wp_options表本身：OPTIMIZE TABLE wp_options;（尤其当autoload数据超3MB时）

注意：执行前务必备份整库；wp_前缀要替换成你实际的表前缀；删完立刻跑wp cache flush或后台“站点健康→清除所有缓存”，否则get_terms()等函数仍会返回旧结果。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！