600+ duplicate queries to wp_options

I am also having the same issue on one of my sites and would love to know how to fix it, so I will watch your post very closely for a solution.

It seems I was able to resolve this.

The background is that I changed web host and the old one had its own cache plugin, which was automatically disabled when I moved over to the new host.

Now, the code from

/wp/includes/options.php, line 186

, below may lead one to think that core WP does its own basic cache, but that’s not the case.

function wp_load_alloptions() {
	global $wpdb;

	if ( ! wp_installing() || ! is_multisite() ) {
		$alloptions = wp_cache_get( 'alloptions', 'options' );
	} else {
		$alloptions = false;
	}

	if ( ! $alloptions ) {
		$suppress = $wpdb->suppress_errors();
		if ( ! $alloptions_db = $wpdb->get_results( "SELECT option_name, option_value FROM $wpdb->options WHERE autoload = 'yes'" ) ) {
			$alloptions_db = $wpdb->get_results( "SELECT option_name, option_value FROM $wpdb->options" );
		}

So, WP attempts to retrieve the cache with wp_cache_get, and if that’s not available it goes ahead and fires a query to db. And there’s an incredible amount of request for access to options, which one generating a query, if no cache.

If you look further down in options.php, you will see that wp_cache_set function exists, but only when changing, adding or delete options.

Only if one read the wp_cache documentation to the end it becomes clear that one should have an external cache plugin.

So, by installing W3 Total Cache and making sure that the object cache is enabled the issue was corrected.

Also, note that you may receive warning from W3 Total Cache concerning db.php file
that may be used by another plugin. If you want the cache the work properly you should accept prompt to let W3 TC replace that file.

Brilliant, thank you for figuring this out.

I installed W3 Total Cache on my problem site and activated the object cache and my queries dropped from around 700 per page to load to just 50.

I’m still not sure what it is about this site in particular that means it’s going crazy with the query options, because I have other sites on the same server without an object cache that are not doing this.

But I’m very glad to have this site behaving itself now! Thanks.

Having a good caching plugin would settle down things a bit but I think that’s not THE solution.

My experience after having and solving the same issue (research further and make your backups before taking any action on the database);

– Minimize the collective size of all the records that have set ‘autoload’ value to ‘yes’ in the wp_options table. To calculate this you can run the query;
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload=’yes’;
If the number you get has more than 6 digits (could be fine for bigger sites), it’s time to clean up some of the garbage in the table (make a backup, first of the full database, and of the wp_options table periodically during the process).

– As the first step I deleted all the transient records as it’s said to be safe most of the time (be careful on live sites): https://stackoverflow.com/questions/10422574/can-i-remove-transients-in-the-wp-options-table-of-my-wordpress-install/11995022#11995022
– Then, run this query;
SELECT option_id, option_name, LENGTH(option_value), autoload FROM wp_options ORDER BY autoload DESC, LENGTH(option_value) DESC, option_name ASC;
Now investigate the option records with large values, and after making sure each option isn’t part of wordpress core, current theme or any of the installed plugins, remove the obsolete ones.

My stats in Query Monitor have greatly improved after taking those steps.

• This reply was modified 6 years, 5 months ago by rwnfrnnd.