WordPress: Heavy slow query - php

Question

In a client website that should display upcoming territory events I got a plugin (called EventsManager), that has been modified to fit our needs.
That plugin, by the way, got an huge query searching for the current events by two parameters, date_start and date_end.
This query affect only one page, and only one function.
$args_filter = $tax_query = array();
$paged = '';
$args_basic = $this->ovaem_query_base($paged, $orderby, $order, $show_past);
switch ($filter) {
[...]
case 'upcomming_showing':
$args_filter = array(
'posts_per_page' => $count,
'meta_query' => array(
array(
'relation' => 'OR',
array(
'key' => self::$prefix . '_date_start_time',
'value' => current_time('timestamp'),
'compare' => '>',
),
array(
'relation' => 'AND',
array(
'key' => self::$prefix . '_date_start_time',
'value' => current_time('timestamp'),
'compare' => '<',
),
array(
'key' => self::$prefix . '_date_end_time',
'value' => current_time('timestamp'),
'compare' => '>=',
),
),
),
),
);
break;
[...]
$args = array_merge_recursive($args_basic, $args_filter, $tax_query);
$eventlist = new WP_Query($args);
return $eventlist;
The resultant query, analized with QueryMonitor is:
SELECT SQL_CALC_FOUND_ROWS wpzt_posts.ID
FROM wpzt_posts
INNER JOIN wpzt_postmeta
ON ( wpzt_posts.ID = wpzt_postmeta.post_id )
INNER JOIN wpzt_postmeta AS mt1
ON ( wpzt_posts.ID = mt1.post_id )
INNER JOIN wpzt_postmeta AS mt2
ON ( wpzt_posts.ID = mt2.post_id )
INNER JOIN wpzt_postmeta AS mt3
ON ( wpzt_posts.ID = mt3.post_id )
WHERE 1=1
AND ( wpzt_postmeta.meta_key = 'ovaem_date_start_time'
AND ( ( ( mt1.meta_key = 'ovaem_date_start_time'
AND CAST(mt1.meta_value AS SIGNED) BETWEEN '1643155199'
AND '1643241601' )
OR ( ( mt2.meta_key = 'ovaem_date_start_time'
AND mt2.meta_value < '1643155200' )
AND ( mt3.meta_key = 'ovaem_date_end_time'
AND mt3.meta_value >= '1643155200' ) ) ) ) )
AND wpzt_posts.post_type = 'event'
AND ((wpzt_posts.post_status = 'publish'))
GROUP BY wpzt_posts.ID
ORDER BY wpzt_postmeta.meta_value+0 ASC
LIMIT 0, 9
Using MySQL 5.7 and memcached, this query got 16,69 seconds to be executed.
Is there a way to optimize that?
Thanks

Answer 1

How the query comes out of set of code is unclear. But a direct query (inserting your parameters as applicable) could be simplified to
SELECT SQL_CALC_FOUND_ROWS
p.ID
FROM
wpzt_posts p
JOIN wpzt_postmeta mtStart
ON p.ID = mtStart.post_id
AND mtStart.meta_key = 'ovaem_date_start_time'
LEFT JOIN wpzt_postmeta mtEnd
ON p.ID = mtEnd.post_id
AND mtEnd.meta_key = 'ovaem_date_end_time'
AND mtEnd.meta_value >= '1643155200'
WHERE
p.post_type = 'event'
AND p.post_status = 'publish'
AND (
mtStart.meta_value BETWEEN '1643155199' AND '1643241601'
OR ( mtStart.meta_value < '1643155200'
AND mtEnd.meta_value > '1643155200'
)
GROUP BY
p.ID
ORDER BY
mtStart.meta_value + 0 ASC
LIMIT
0, 9
So, not knowing specifically about WordPress and how you have it configured, Does your data allow for multiple start and end time entries for a SINGLE POST ID? If so, that will result in a Cartesian Result thus over multiplying the instances.
Are you trying to count how many UNIQUE Post IDs are found, or total records found for all the meta-data entries associated with said posts.
For indexes, I would suggest having the following
Table Index on
wpzt_posts ( post_type, post_status, id )
wpzt_postmeta ( post_id, meta_key, meta_value )
I removed the CAST(meta_value AS SIGNED) since the records associated with date/time context will always be numeric, its not like you would ever encounter a time of 'this is bad data' and thus influence a bad numeric conversion. As such, the function call makes it non-sargeable and thus will not utilize an index. But if all instances of a start/end time are all digits, you wont have that confusion -- unless the physical lengths of those numeric representations actually are longer or shorter, but even in that case, a smaller number would probably indicate a date sooooo far back, it would not even be in the range being considered and thus no impact.