wp_options autoload
古いバージョンの WP だと wp_options の autoloadに インデックスがない。
Update: The reason the query is being logged is it doesn't use an index. The query time is 0, i.e. it actually executes fast. You can unset the "log-queries-not-using-indexes" option if you don't want these to be logged.
The wp_options table has no index on autoload(it now should, it was added to WP core schema Aug 15, 2019), so the query ends up doing a full table scan. In general that table shouldn't get too large, so it's not a problem, but I'm guessing that's somehow happened in your case.Adding an index might solve the problem, but as TheDeadMedic pointed out in the comments, it might not if the values of autoload are either majority yes, or evenly distributed between yes and no:
First, do this query to see what the distribution looks like:
SELECT COUNT(*), autoload FROM wp_options GROUP BY autoload;if a large majority of them are set to 'no', you can solve the problem for now by adding an index on autoload.
ALTER TABLE wp_options ADD INDEX (`autoload`);However, you might want to get to the bottom of why that table has gotten too large. Possibly some badly written plugin doing something fishy.
https://wordpress.stackexchange.com/questions/71691/slow-query-for-the-wp-options-table
wp_posts guid
Workaround
A way to go around this problem is to (at least temporarily) add indexes for these fields.
You can do this using two SQL queries like the following ones:ALTER TABLE `wp_posts` ADD INDEX `guid` (`guid`); ALTER TABLE `wp_postmeta` ADD INDEX `meta_value` (`meta_value`(512));https://wpml.org/errata/performance-considerations-for-the-wpml-media-setup-on-large-sites/
please get the plugin's author to add the index from the plugin. this field isn't used in where clauses in WP, and the index would be useless for other users -- but still goggle up db space.
#7633 (Lack of an Index on wp_posts.guid Slowing Down Queries) – WordPress Trac 2009
categories-images 2.4.2
