wp_options表变慢导致全站卡顿，因WordPress每次加载均全量读取autoload='yes'选项，超2MB时反序列化严重拖慢响应；需用SQL查autoload体积、建复合索引、清理transient及冗余选项并优化表。
为什么 wp_options 表变慢后整个网站都卡？
因为 wordpress 每次加载页面（前台或后台）都会执行 wp_load_alloptions()，把所有 autoload = 'yes' 的选项一次性读进内存。如果这个集合体积超过 2mb（比如达到 5–10mb），php 解析和反序列化就会明显拖慢响应——你看到的“后台打不开”“首页白屏”，往往不是 php 内存不足，而是这一轮全量加载耗时太久。
怎么快速判断 autoload 数据是否过载？
在 phpMyAdmin 中打开你的 WordPress 数据库，选中 wp_options 表，点击顶部的 SQL 标签，粘贴并执行：
SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';
返回结果单位是字节。注意看数值：
- ＜ 300KB：基本健康
- 300KB – 2MB：开始有压力，建议清理
- ＞ 2MB：大概率已成瓶颈，必须处理
别只看行数——有些插件存一个超长的序列化数组，一行就能占几 MB。
加索引前先确认 autoload 分布是否值得加
索引只对查询效率有帮助，但前提是查询条件真用得上。执行这两条语句看比例：
立即学习“PHP免费学习笔记（深入）”；
SELECT COUNT(*) FROM wp_options WHERE autoload = 'yes';
SELECT COUNT(*) FROM wp_options WHERE autoload = 'no';
如果 autoload = 'no' 的行数远多于 autoload = 'yes'（比如 8:2 或更悬殊），说明表里大量数据本不该自动加载，这时加索引才有效。否则加了也白加——MySQL 优化器可能直接走全表扫描。
真正该加的索引是复合索引：
CREATE INDEX autoloadindex ON wp_options (autoload, option_name);
不是只给 autoload 加单列索引。因为 WordPress 查选项时，实际是 WHERE autoload = 'yes' AND option_name = 'xxx' 这种组合条件，复合索引才能命中。
删残留比加索引更能立竿见影
索引解决的是“查得慢”，但根源常是“不该查的太多”。最有效的一步永远是清理：
- 先删掉所有
_transient_和_site_transient_开头的选项：DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';
- 再查出长期没更新、又不是核心选项的
autoload = 'yes'条目（比如插件卸载后留下的pluginname_settings），手动设为autoload = 'no'或直接删掉 - 别碰
option_name是siteurl、home、active_plugins、theme_mods_*这些——删错会导致网站崩溃
做完清理后，记得在 phpMyAdmin 里对 wp_options 表点右键 → Optimize table，回收碎片空间。这步很多人跳过，但 InnoDB 表删除大量行后不优化，磁盘占用和查询性能都不会真正释放。
真正卡住的地方，往往不在 SQL 语句写得多漂亮，而在于有没有意识到：autoload 不是开关，是责任——每个设为 yes 的选项，都在拖慢你每一次页面请求。
