我一直在跟踪基于WP的网站的慢查询日志（将long_query_time的默认值设置为10），并且我注意到以下查询经常被记录-
# User@Host: root[root] @ localhost []
# Query_time: 0 Lock_time: 0 Rows_sent: 394 Rows_examined: 458
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';我不明白这么小的表可能要花这么多时间来执行。这仅仅是其他问题的征兆吗？（当前在专用VM上运行Moodle，phpbb和WP）。
Answers:
更新：正在记录查询的原因是它不使用索引。查询时间为0，即实际上执行得很快。如果您不希望记录这些日志，则可以取消设置“ log-queries-not-using-indexes”选项。
wp_options表在自动加载时没有索引，因此查询最终将进行全表扫描。通常，该表不应太大，所以这不是问题，但是我猜这是在您的情况下发生的。
添加索引可能会解决此问题，但是正如TheDeadMedic在注释中指出的那样，如果autoload的值要么是多数，要么是在yes和no之间平均分配，则可能不会：
首先，执行以下查询以查看分布情况：
SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;如果其中大多数设置为“ no”，则可以通过在自动加载时添加索引来解决该问题。
ALTER TABLE wp_options ADD INDEX (`autoload`);但是，您可能想弄清楚为什么该表太大了。可能是一些写得不好的插件造成了一些麻烦。
我的wp_options表只有大约235行数据。我尝试为表编制索引，但没有帮助。
原来，该表中已插入约150个瞬态选项，但尚未自动删除。
我不知道它是否相关，但是我一直在浏览我的/var/log/apache2/access.log文件，并注意到有多个（大概是被盗用的）Amazon Web Services服务器（IP地址以54开头）。 XXX和32.XXX）一直试图利用/~web-root-dir/xmlrpc.php。
经过一些故障排除后，我在wp_options表中查询了包含“瞬态”的选项名称。
从wp_options中选择*，其中option_name如'％transient％'；
该查询返回的字段之一是“ option_value”，其数据类型为LONGTEXT。根据mySQL文档，LONGTEXT字段（每行）最多可容纳4 GB的数据。
当我执行查询时，某些行（记住正在与包含“瞬态”的行一起使用）在option_value字段中具有大量数据。查看结果，我还看到了将命令注入wp-cron进程的企图，希望它们能在cron周期内执行。
我的解决方案是删除所有“瞬态”行。这不会伤害服务器，因为“临时”行将自动重新填充（如果应该存在）。
完成此操作后，服务器再次响应。
查询以删除以下行：
从wp_options中删除，其中option_name如'％transient％'；
我也已将AWS IP地址/ 8超级块添加到我的防火墙中（-：