站点跑了两三年，后台文章列表要转好几秒，前台首屏也越来越钝，可服务器负载不高、内存也没吃满。这种慢但不忙的状态，值得先去数据库里翻一眼wp_options表：它存的是一条条键值对，其中标记为自动加载的那些，每次页面请求都会被一次性读进内存，项数一多，等于每个访客都在替你背这批数据。
用一条排序语句把自动加载的数据按体积列出来，数清条数和总字节。
如果查出来只有几十条、总共不到一百KB，这张表就不是元凶，别在这儿耗时间，直接去看查询和索引。反过来，条数上了四位数、总量过了1MB就值得动手，先把占地方又没用的挑出来。
卸载过的插件留下的设置项排第一，插件删了，它写在表里的记录还在，键名一般带着旧插件的缩写；过期的transient排第二，也就是带_transient_前缀的临时缓存，正常该自己过期，插件写得糙就会一直堆着；再往后是主题的theme_mods，换过几次主题之后旧主题的配置也留着。老版本的autoload字段是yes和no，新版本换成on、off、auto这类枚举，写查询条件时按自己站点的版本走。
体积大、但只在特定页面才用得到的选项不用删，把autoload从开启改成关闭就行，它不会跟着每次请求一起载入。判断依据是这条选项是不是每个页面都要读——如果只有某个插件自己的设置页会用到它，就没有理由让它自动加载。仍在用的插件、WordPress核心自己的选项一律不动，删错一条可能直接让后台登录失效，动手之前整表备份这条没有例外。改完刷新两次后台，再用同一条语句数一遍，条数没下来就是还有插件在往回写。
确定已经卸载的插件留下的键、带超时值且已经过期的transient，这两类可以直接删。删完刷新一次前台和后台，确认没有报错。
装了对象缓存的话，这批自动加载的数据可以整体挪出数据库，改成从内存里读，效果比逐条清理更直接。前提是缓存服务真的在跑——后台显示已连接还不够，去前台刷两次页面，看命中率有没有数字，不然插件只是一个空开关，请求照样打到数据库。
清理之后后台还是慢，问题就不在这张表。把页面执行的查询打开看一遍，找耗时最长的那几条，用执行计划确认走没走索引；再看文章数和评论数，几十万条数据配上没建索引的元数据表，同样能把后台拖住。慢查询日志开着的话，这几条会自己浮出来，翻最近一小时的记录就够。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
