I found a slow query in my MySQL processlist: SELECT /*!40001 SQL_NO_CACHE */ * FROM `cache_metatag`

On a large site, my cache_metatag table has well over 100,000 rows so this query moves quite a large amount of data around. Is there some reason we need to select the entire cache_metatag table during a request?

Comments

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Issue tags: +Performance

I have no idea why that query would be ran, if you look for all of the cache_get() calls in the module they *all* pass an ID.

I suggest changing your site's includes/cache.inc to do an extra check for when the $bin value is 'cache_metatag' to see what the $cid value is, see if you can find then use debug_backtrace() to find out where it's coming from.

mfb’s picture

mfb
they or he
commented
Status: Active » Closed (works as designed)

OK I cannot find a place where it would be generated by the codebase, so I now believe this query was caused by a developer making a database dump of the site? I believe what happened was, not using the --quick or --single-transaction parameters resulted in locking all tables during the slow database dump..

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Issue tags: -Performance

Ok, glad to hear it was something simple :)