WordPress把站点标题、插件开关、主题设置都放在wp_options这张表里。带autoload标记的行会在每次请求开头被一次性读出来，装进内存。行数少、体积小的时候这一步几乎不花钱。等行数和体积都上去，每个请求都要多背一份。
WordPress6.6改了这套机制，autoload这一列原先只有yes和no两个值，现在可以是on、off、auto、auto-on、auto-off五种。老数据没有被迁移，yes和no仍然按on和off来对待，所以升级过的站点里，同一列上两种写法混着存在。
这一改直接把老查法打废了，网上流传的统计语句大多只查autoload等于yes。在6.6之后的站点上，这一句会漏掉所有新写入的行，还会漏掉标成auto和auto-on的行。跑出来也有个数字，只是永远偏小，看着还挺放心。
wp_autoload_values_to_autoload()这个函数返回的是yes、on、auto-on、auto四项，统计时把这四项都列进条件就对了，算总量就按这四项求和，挑大户就按体积倒序取前二十行。表前缀改过的站点记得把wp_换成自己的前缀，不然语句直接报错。
新写入的选项只要超过150KB，WordPress就不再默认给它autoload，除非代码明确要求，这个上限可以用wp_max_autoloaded_option_size这个过滤器改。站点健康里同时加了一项检查，自动加载的选项总量超过800KB就报严重问题，阈值能用site_status_autoloaded_options_size_limit调。两条都只对新写入生效，之前已经躺在库里的行照旧自动加载。真正要处理的时候，找大户的思路是按体积排，不是按条数。一百条几十字节的孤立记录加起来，不如一行2MB的序列化数组占地方。体积靠前的通常是这几类来源，已经删掉的插件留下的设置、备份和安全插件往单个选项里写的日志、页面构建器存下的一大坨配置。
关autoload要分情况看，确定属于已卸载插件的行，删掉比关掉干净；属于还在用的插件的大行，把autoload改成off能立刻减负，但只在那个选项偶尔才被读到时才划算。每次请求都要用的选项被关掉，WordPress会改成单独发一次查询去取，成本只是换了个位置，页面不会因此变快。
动手之前先导出数据库，改动只涉及wp_options，回滚成本不高，但没有备份就没有回滚。改完清一次对象缓存，再回站点健康看那一项有没有转成正常；清理是一时的，插件还按原来的方式写，几个月后同一批行会重新长回来，隔一段时间看一眼体积比一次清干净更有用。
A5创业网 版权所有