在WordPress服务的每个页面的开头，都有一个MySQL调用来获取选项：
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';因为autoload列上没有索引，所以MySQL必须查找所有行。
我还遇到了对此答案的评论，说即使有索引也不会提高性能。
在我的应用程序中，我使用了很多瞬态值来替代会话。他们的工作很棒，我有自己的垃圾回收程序。我注意到在wp_options表格中，我的瞬态值（以开头的值_transient_）都具有autoload=no。我期望wp_options表的行数会随着并发用户数的增加而增加。
我想知道为什么表格是这样设计的。我应该为我的特殊情况创建索引吗？
Answers:
没有索引，因为对它的需求从未足够强。
在票证＃14258中，建议使用autoload=yes该选项，但是由于大多数选项默认使用，因此无论如何都将忽略索引。
还有＃24044尚待解决的故障单_在wp_options中添加索引以帮助/改善性能_。
我认为您应该创建一个索引。它将生存升级。这可能对您的性能没有帮助，但是您可以向该故障单添加真实的统计数据。
2019年11月更新
该索引已添加到WordPress 5.3。最后。请参阅上面提到的票证＃24044和发行者的发行说明。
请注意，如果现有索引具有相同的名称，则在升级过程中将收到警告。
从变更集：
大多数站点都不会受到此更改的影响，但是在中具有大量行的站点
wp_options（其中只有少数行已autoload设置）将获得显着的性能提升。不幸的
是wp_options，在中有很多行的站点中设置了许多行，这些站点autoload在运行非常慢的查询之上会导致性能下降，但这应该是少数情况。
wp_options.autoload。来源：make.wordpress.org/core/2019/10/15 / ...和... core.trac.wordpress.org/ticket/24044#comment:87 ...对提议此功能的@DanBUK表示感谢在2013
我正在Debian Squeeze大型实例上运行3个WP博客，并正在调查为什么mysql在200％CPU使用率和3到6之间的系统负载下卡在该主机上。查看mysql中的“显示进程列表”，我们理解wp_option表涉及此问题，因此我们执行了：
alter table wp_options add index autoload_idx(`autoload`);执行此操作后，如上图所示，mysql负载急剧下降至1％，实例平均负载现在为0.10。
我们正在使用一些插件，因此在代码中的某个地方可能存在循环，这可能是一种特殊情况，但是在我们的情况下，性能的变化是非常惊人的。
我们的wp_options表有347行。
select *一次。而是查询每个选项，这就是为什么放置索引会产生很大的不同的原因。
尽管@fuxia 接受了一些“声称的”原因（大多数原因是Automattic的员工在各种Trac票证上声称的原因）的答案，但WordPress Core不包含表中自动加载选项索引的根本原因wp_options是： Automattic担心这会对仍在使用MyISAM引擎的MySQL数据库的性能产生负面影响。
具体来说，他们指出WordPress.org网站本身是一个非常老旧/复杂的数据库，它是一个示例网站，其性能会受到此类索引的影响。
在过去的9年中，几乎所有其他未添加索引的原因（是的，自2010年以来，对于Trac票证＃14258和自2013年以来，对于Trac票证＃24044）一直被数十名成员反复证明为不正确WordPress社区，但涉及Automattic的员工反复忽略了几个独立的基准测试，并转回提及MyISAM问题。
值得庆幸的是，在2019年底，PHP 7.2现在是WordPress Core推荐的“默认”版本，而InnoDB引擎现在在5.5之后的MySQL版本中是默认值，并且来自@DanBUK在内的各种开发人员不断施加压力，这些问题困扰了很多年。 ，Automattic最终屈服了，并决定在2019年11月从WordPress 5.3+开始添加自动加载索引。
LittleBizzy的我们推出了第一个已知的插件，如果不存在该索引，该插件会自动添加索引，该索引仍在GitHub上可用，并会定期下载。请注意，如果您正在运行WP Core 5.3+，则无需再将此类插件安装到WordPress堆栈中...
autoload列上设置索引。