MySQL - Why specific query doesn't use cache?
When either table is modified, all entries in the QC are removed (pruned) from the QC for that table.
If the query has too big a resultset, it won't go into the QC.  (Please provide SHOW VARIABLES LIKE 'query_cache*';


Do you have this on wp_postmeta: PRIMARY KEY(post_ID, meta_key) ?  If you can switch to that, performance should improve when the QC is not used.  If you have trouble, let's see SHOW CREATE TABLE wp_postmeta; some WP versions are really lame when it comes to optimizing that schema.

Do you need the GROUP BY?  JOIN...GROUP BY often suffers from the explosion-implosion syndrome that makes such queries slow.  There may be a workaround.

Will you be "paginating"?  If so, use of OFFSET is inefficient.

Getting rid of SQL_CALC_FOUND_ROWS will speed up the query.

That is a confusing query, what is it trying to do?

Index

PRIMARY KEY (meta_id),         -- useless and slows things down
KEY post_id (post_id),         -- inadequate
KEY meta_key (meta_key(191))   -- prefixing is next to useless


Change to this

Change `meta_key` from VARCHAR(255) to VARCHAR(191)
PRIMARY KEY (post_id, meta_key)
no other indexes unless you ever search for meta_key without post_id


Notes:


You probably don't have very long keys, so changing to 191 may be safe.  You could run SELECT MAX(CHAR_LENGTH(meta_key)) FROM .. to see what the current max is.
If you can't shrink to 191, then try to upgrade to 5.6.3 / 5.5.14, which allows you to increase the limit (with some effort), or 5.7.7, which allows it by default.
'Composite' keys are often better than single-column keys, especially in this case.
Having the primary access pattern be the PK makes it faster.
These improvements may not help that particular contorted query, but it will help the table in other ways.


(I have been ranting about WP for years.  I would be happy to advise them.)