WordPress后台变慢的原因：autoload的记录太多，wp_options每次请求都要全量加载一遍

一个站跑了两年的WordPress，首页三百毫秒，后台打开文章列表要五秒多。这个变慢是渐进的，最近三个月才明显。PHP执行时间正常，慢查询日志里也没有明显的大表扫描。装上Query Monitor，每个页面顶部都跳出一行红字，说options查询占了两秒。

wp_options表里有一列叫autoload。标成自动加载的行，会在每次请求开始时被一次性全部查出来。查出来的结果塞进内存里的alloptions，后面整个请求都从这份副本读。这种全量加载本来是为了让常用配置少查几次库，代价是条目一多，每个请求都要背着这一整包数据走。

条目是怎么多起来的。装过的插件卸载后常常留着配置行，主题换过几轮也留着旧键，缓存插件、SEO插件、表单插件各自往里写_site_transient_开头的记录。这些行多数默认就是自动加载，删插件的时候没人去动它们，一年下来攒到上千条不算稀奇。

先量体积再动手。跑这条SQL：SELECT COUNT(*) AS cnt, ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto-on');。条目一百到三百、总量几百KB属正常。条目过千或者体积超过1MB就该清了。再看哪几条最大：SELECT option_name, LENGTH(option_value) AS len FROM wp_options WHERE autoload IN ('yes','on','auto-on') ORDER BY len DESC LIMIT 20;。排在前面的往往是某个插件的缓存数据，或者一份序列化过的配置。

清理分三类。第一类明显可删：名字里带_uninstall、_deactivated，或者前缀对得上但插件已经不在列表里的，用wp option delete加上选项名删掉，删之前先把值导出来存一份，万一有插件依赖它能还原。第二类是临时缓存：_transient_和_site_transient_开头的，过期了会自动清，没清掉的用wp transient delete --expired批量处理，不必一条条手工删。第三类是在用但不必自动加载的：wp option update加上--autoload=false，把它从每次请求的包里摘出去，配置本身还在，需要时再单独查一次。三类里第一类收益最大，也最容易误删。动手前先跑一次wp db export把整库导出来，几十兆的文件换一次安心的回滚，比事后翻binlog省事得多。

WordPress 6.6起这一列的含义变细了，除了on和off，还多了auto-on和auto-off。auto-on表示按需判断，核心会在选项被读取时再决定要不要转成on。升级到6.6之后，原来的yes会自动迁成on，no迁成off。老插件如果还在往这一列写yes，可能写不进去，或者被当成非法值处理。升级后如果有插件报写入失败，先查它有没有适配新值，别急着怀疑数据库权限。清理完不用重启，下一次请求就会按新的集合拼包。

这个站的条目从1400条降到310条，总量从2.1MB降到180KB，后台列表页回到八百毫秒。你要是隔一周再看一次条目数，发现又涨回去，说明有插件在反复写入，那就不是清理能解决的，得把它找出来关掉。找的办法是隔两天各导一份选项名清单，用diff比一遍，新冒出来的那批键名前面通常挂着插件自己的前缀。