Today (and on many days in the other weeks) we find our database under enormous pressure, because this one selection is fired again and again… Do you have an explanation and advice? This stops us from being productive.
EXPLAIN SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) WHERE 1=1 AND wp_posts.ID NOT IN (313309) AND ( wp_term_relationships.term_taxonomy_id IN (3486)) AND wp_posts.post_type = ‘post’ AND ((wp_posts.post_status = ‘publish’)) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 4:
*** row 1 ***
table: wp_term_relationships
type: ref
possible_keys: PRIMARY,term_taxonomy_id
key: term_taxonomy_id
key_len: 8
ref: const
rows: 77885
Extra: Using where; Using temporary; Using filesort
*** row 2 ***
table: wp_posts
type: eq_ref
possible_keys: PRIMARY,type_status_date
key: PRIMARY
key_len: 8
ref: hasepost.wp_term_relationships.object_id
rows: 1
Extra: Using where
Hello @nachtwache !
Our developers are aware of this issue and try to synthesize the composer, which is big, and fix the major problems of the theme and speed.
I recommend you use fewer features on the page, so the requests will be less as well.
Thank you!
Hello Bettina, we already stripped down many features and find the “slow backend” problem has been growing over the last updates.
We are now at a point, where even a radical solution (bye bye tagdiv) seems to be the best solution for us. We love your theme and the support – but speed is crucial, and this is a problem that grows faster than our user base or the numbers of articles we have published.
