应执行SQL语句“SELECT option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%' ORDER BY size_bytes DESC LIMIT 20”定位占用空间最大的瞬态选项，并重点检查size_bytes超1MB或autoload='yes'的异常项，再据其类型决定删、禁用或仅改autoload为no。
查 wp_options 表里哪些 option_value 占用空间最大
wp_options 表中体积过大的临时选项（_transient_、_site_transient_）常导致查询变慢、内存溢出，甚至拖垮后台响应。phpMyAdmin 本身不提供“按字段大小排序”的界面按钮，但可以用 SQL 快速定位：
在 phpMyAdmin 的 SQL 标签页执行：
SELECT option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%' ORDER BY size_bytes DESC LIMIT 20;
注意：LENGTH() 返回的是字节长度，不是字符数，对序列化字符串更准确；wp_options 表前缀需与你实际一致（如 wp123_options）。
- 结果中 size_bytes 超过 1MB 的项，基本可判定为异常——正常瞬态数据极少超过 100KB
- 若看到大量
_transient_timeout_*对应的_transient_*值特别大，说明插件写入了未压缩的原始 HTML/JSON/二进制数据 - 某些缓存插件（如 WP Rocket）会把整个页面 HTML 存成瞬态，但通常会压缩；若没压缩且没设过期，就会越积越大
识别是否被 autoload 拖累
即使单个瞬态不大，如果被标记为 autoload = 'yes'，WordPress 就会在每个请求时把它从数据库读进内存——几百个这样的小瞬态加起来，照样吃光 PHP 内存。
立即学习“PHP免费学习笔记（深入）”；
执行这句查自动加载的瞬态：
SELECT option_name, LENGTH(option_value) AS size_bytes FROM wp_options WHERE (option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%') AND autoload = 'yes' ORDER BY size_bytes DESC;
- 任何
_transient_类型的数据都不该设autoload = 'yes'——这是严重设计错误 - 如果你发现
option_name是_transient_feed_...或_transient_dash_...却 autoload=yes，大概率是某个插件硬编码写错了 - 修复方法：直接编辑该行，把
autoload字段值改成no（注意是字符串'no'，不是数字 0）
删还是不删？判断依据是什么
不是所有大瞬态都该删。WordPress 和插件依赖部分瞬态做功能缓存，误删可能引发短期异常（比如 RSS 小工具空白几小时）。安全清理要分情况：
-
可立即删：名称含
_timeout且对应时间戳已过期（用SELECT option_value FROM wp_options WHERE option_name = '_transient_timeout_xxx';查出时间戳，再SELECT FROM_UNIXTIME(1234567890);看是否早于当前时间） -
建议先禁用再观察：名称含
dash_、update_、plugin_install_的大瞬态——这些多来自后台检查逻辑，删了会触发重新拉取，可能加重服务器负担 -
别碰但要记名：以
_transient_doing_cron或_transient_timeout_wp_update_plugins开头的——它们控制关键调度，删了可能导致定时任务失效或插件更新异常
真正该警惕的，是那些名字毫无规律、value 里出现 base64 编码或大段 HTML 的 _transient_ 项——这类基本是插件滥用瞬态存储，删掉后顶多让对应功能首次加载稍慢，不会破坏功能。
为什么不能只靠插件一键清理
很多“数据库优化”插件宣称能“自动清理瞬态”，但实际行为很粗糙：
- 它们通常只删
_transient_timeout_*过期项，却不管对应的大 value 是否还存在（造成孤儿数据） - 不检查
autoload设置，清理完下次启动又自动加载回来 - 批量 DELETE 可能锁表，尤其在高并发站点上，导致后台卡死几分钟
- 有些插件自己就是瞬态大户（比如某知名 SEO 插件会每小时存一个 2MB 的分析报告到
_transient_seo_report_*）
手动用 phpMyAdmin 定位 + 有选择地删或改 autoload，比盲目点“优化”按钮靠谱得多。关键是：先看，再判，最后动——别让“清理”变成新的故障源。
