wp_options 表两百多兆 autoload 里塞了什么

SELECT option_name, LENGTH(option_value) len FROM wp_options
WHERE autoload='yes' ORDER BY len DESC LIMIT 10;
wp transient delete --expired
UPDATE wp_options SET autoload='no' WHERE option_name='x';

备份时发现 wp_options 表已经两百多兆 全站才三千篇文章 后台每次请求都要从这张表里读取上百行数据。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。

追下去是这么回事：插件把缓存 日志 任务队列全都塞进 options 表 autoload 字段还留着 yes 每个请求都会一次性全加载 几年下来就积成了一张大表 越拖越难清。

「wp_options 膨胀」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。

处理上按这个顺序：先按 autoload 字段和值长度排序 看清排在前面的几个 option_name 到底占了多少空间；过期 transient 插件日志和备份快照可以直接删 删之前确认没有插件还在读这些键；确实要保留的改成 autoload=no 让它在用到时再单独查一次 别每页都带上。

确认没问题再收工，首屏查询的 options 行数降到几十行 整张表体积回落到十兆以内 基本稳定。