Hi, Dimitri. Ouch! that is a lot of metadata!
From a database-analyst point of view it would be helpful to see MySQL’s execution plan for your query. Could you please run this plugin’s monitor feature for a few minutes while those nasty queries run, then upload it?
Also please upload your site’s metadata: visit this plugin’s About tab and choose Upload Metadata.
I’ll take a look.
Thank you Ollie,
I uploaded as 7xGMUHLf
I had added these
CREATE INDEX dv_p ON wp_posts(ID, post_date, post_type, post_status);
CREATE INDEX dv_tt ON wp_term_taxonomy(term_taxonomy_id, taxonomy, term_id);
CREATE INDEX dv_lmd ON wp_posts(post_status, post_type, post_modified_gmt);
CREATE INDEX dv_cid ON wp_posts(post_status, post_type, post_password, post_date, ID );
CREATE INDEX dv_cidm ON wp_posts(post_status, post_type, post_password, post_date, post_modified, ID );
CREATE INDEX dv_tro ON wp_term_relationships(object_id);
But was asked by your plugin to redo the posts…
So now the indexes are back to:
PRIMARY ID
INDEX post_name
INDEX post_parent, post_type, post_status
INDEX post_type, post_status, post_date, post_author
INDEX post_author, post_type, post_status, post_date
FULLTEXT post_title, post_content
I also have the problem like you. DO you have any solution for this case ?
THank you
Well there is no easy solution.
In my case I added my custom indexes as well and it goes much much better.
The wordpress core team also took notice of the count(*) issue and I guess that they will fix it in a subsequent release.
I will also advise to optimize your connection to your mySQL (buffer pool size etc).
I just tested with your solution about changing the count(*) to count(ID) but i see it still has the query about ” SELECT p.ID FROM wp_posts AS p INNER JOIN wp_term_relationships AS tr ON p.ID = tr.object_id INNER JOIN wp_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE p.post_date < ? AND p.post_type = ? AND tt.taxonomy = ? AND tt.term_id IN (?,?) AND ( p.post_status = ? OR p.post_status = ? OR p.post_status = ? ) ORDER BY p.post_date DESC LIMIT ? ”
any time
I don’t know how to stop it.
Do you have any solution ?
Thank you
What do you mean to stop it? You just can’t it is used be WP/WOO
What you can do is to add indexes taking into account the post_status, post_date and post_type.
I think that Ollie will tell me off for this but please try this index and see if/how it improves your execution time:
CREATE INDEX dv_p ON wp_posts(ID, post_date, post_type, post_status);
Dmitiry, nobody’s telling anybody off for struggling with these performance issues! This stuff is a huge pain in the xss neck. I’ve tried lots of indexes to optimize these taxonomy queries, and so far nothing has helped. As you said, core team people are working on a caching strategy.
You can use the MariaDB command ANALYZE FORMAT=JSON query — or the MySQL command EXPLAIN ANALYZE — to get some information about the database’s query plan. This will tell you whether it used any index to access each table in the query, and if so how it used it.
The process of creating this plugin involved trying different indexes and studying those query plans. It’s a good idea to do the same if you try other indexes.
By the way, persistent object caches (redis, memcached, and soon SQLite — watch this space!) do help make sites faster with these taxonomy queries.
In the wp_posts table COUNT(*) and COUNT(ID) do precisely the same thing in the same amount of time. The difference beween the two is that the second one doesn’t include null values in the count. But ID is the primary key of the table so the database knows a priori it has no null values.
-
This reply was modified 3 years, 6 months ago by
OllieJones.
-
This reply was modified 3 years, 6 months ago by OllieJones.
-
This reply was modified 3 years, 6 months ago by OllieJones.
Ollie I am Greek and not Russian (so it is better to remain a Dimitris rather than a Dmitry 🙂 )
For the record to just say that following your suggested improvements (together with mine stated above) as well as the removal of the unnecessary post meta (e.g. reducing the number of rows to a mere 25 million) for that portal I started this thread, now it has become 10 times faster than what it used to be, and two times as fast by any other Greek portal.
See here: https://www.webpagetest.org/video/compare.php?tests=221102_AiDcMJ_13T,220928_BiDcCC_915,220928_AiDcR8_B8,220928_AiDcFX_AA2,220928_BiDcA5_96E,220928_AiDcK7_9TC,220928_BiDcDZ_9DS,220928_AiDcNY_9HF,220928_BiDc91_9E6,220927_BiDc6A_HDN,220928_BiDcG2_95K
(the new is no.1 while its previous incarnation was no.10)
Obviously, WP Rocket helped enormously, the conversion of the images from jpg to webp as well using Redis and Varnish on top (using Linode London via Cloudways))
Please pardon me for misspelling your name, Dimitris.
