7logic

Добрый день!

Дело в том, что WP_Query – всего лишь инструмент в руках разработчика, и его важно правильно использовать. Мы поддерживаем доработку плагинов и не хотим плодить хаки в проектах для решения проблем. Я углубился в проблему, разобрался и хочу предложить вам решение. Буду признателен, если найдёте время для анализа предложенного решения и доработки плагина. Кстати, вы поддерживаете pull request через github?

Предлагаю добавить в настройки плагина фильтр по дате создания записей – “Выгружать записи не старше %s”. Например, можно добавить список с вариантами 1 год, 6 мес, 3 мес, 1 мес, 2 нед. При включении этого фильтра добавлять date_query в args[] для WPQuery. Подобная настройка была бы полезна и для плагина RSS for Yandex Zen.

Ниже я опишу технические детали, почему это решение работает.

Указанный в тикете запрос относится к следующему участку кода:

$args = array(
    'paged' => $paged,
    'ignore_sticky_posts' => 1,
    'post_type' => $yttype,
    'post_status' => 'publish',
    'posts_per_page' => $ytrazbnumber,
    'tax_query' => $tax_query,
    'meta_query' => array(
        'relation' => 'OR',
            array('key' => 'ytrssenabled_meta_value', 'compare' => 'NOT EXISTS',),
            array('key' => 'ytrssenabled_meta_value', 'value' => 'yes', 'compare' => '!=',),
    )
);
$args = apply_filters( 'yturbo_query_args', $args );
$query = new WP_Query( $args );

Аналогичная проблема есть в плагине RSS for Yandex Zen на следующем участке кода:

$args = array('ignore_sticky_posts' => 1, 'post_type' => $yztype, 'post_status' => 'publish', 'posts_per_page' => $yznumber,'tax_query' => $tax_query,
'meta_query' => array('relation' => 'OR', array('key' => 'yzrssenabled_meta_value', 'compare' => 'NOT EXISTS',),
array('key' => 'yzrssenabled_meta_value', 'value' => 'yes', 'compare' => '!=',),));

$args_alt = apply_filters( 'yzen_query_args', $args, 8 );
if (isset($args_alt) && is_array($args_alt)) $args = $args_alt;
$query = new WP_Query( $args );

Указанный выше порядок аргументов заставляет WP генерировать неоптимальный SQL-код с несколькими LEFT JOIN, что вызывает сборку временной таблицы, которая на больших БД может не влезать в память и начинает сбрасываться на диск. Проблема не новая, проявляется на запросах WPQuery, где включён meta_query с логикой OR, проблема описана в тикетах WP 6-летней давности:
https://core.trac.wordpress.org/ticket/24093
https://core.trac.wordpress.org/ticket/30044

Оптимизация в ядре так и не была проведена, решение кроется в декомпозиции запроса с применением подзапросов или наложении ограничений по индексу, чтобы изменить план запроса.

На мой взгляд, самым правильным решением является наложение фильтра по полю post_date, которое есть в индексе. В нашем примере ограничим выборку записей 1 месяцем, получается такой запрос:

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) LEFT JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'ytrssenabled_meta_value' )  LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id ) WHERE 1=1  AND ( 
  wp_term_relationships.term_taxonomy_id IN (1,4,16,178,591,1113,1465)
) AND ( 
  wp_postmeta.post_id IS NULL 
  OR 
  ( mt1.meta_key = 'ytrssenabled_meta_value' AND mt1.meta_value != 'yes' )
) AND wp_posts.post_date >= '2020-07-18' 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, 40

План выполнения запроса изменился кардинально:

+----+-------------+-----------------------+------------+-------+---------------------------------------------------------------------------------------+------------------+---------+---------------------------+------+----------+-----------------------------------------------------------+
| id | select_type | table                 | partitions | type  | possible_keys                                                                         | key              | key_len | ref                       | rows | filtered | Extra                                                     |
+----+-------------+-----------------------+------------+-------+---------------------------------------------------------------------------------------+------------------+---------+---------------------------+------+----------+-----------------------------------------------------------+
|  1 | SIMPLE      | wp_posts              | NULL       | range | PRIMARY,type_status_date,type_status_modified_gmt,status_type_password1_date_modified | type_status_date | 169     | NULL                      |  719 |   100.00 | Using where; Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | wp_term_relationships | NULL       | ref   | PRIMARY,term_taxonomy_id                                                              | PRIMARY          | 8       | u100007_ramns.wp_posts.ID |    2 |    34.26 | Using where; Using index                                  |
|  1 | SIMPLE      | wp_postmeta           | NULL       | ref   | post_id,meta_key                                                                      | post_id          | 8       | u100007_ramns.wp_posts.ID |  232 |   100.00 | Using where                                               |
|  1 | SIMPLE      | mt1                   | NULL       | ref   | post_id                                                                               | post_id          | 8       | u100007_ramns.wp_posts.ID |  232 |   100.00 | Using where                                               |
+----+-------------+-----------------------+------------+-------+---------------------------------------------------------------------------------------+------------------+---------+---------------------------+------+----------+-----------------------------------------------------------+
4 rows in set, 1 warning (0.00 sec)

Такой запрос выполняется в десятки раз быстрее, а результат выполнения запроса тот же (в проекте добавляются десятки записей в день).

Резюмируя, хочу добавить, что ту же логику возможно реализовать через встроенные в код плагина фильтры yturbo_query_args и yzen_query_args (для плагина RSS for Yandex Zen), но добавление фильтра по дате в настройки плагина видится наиболее правильным решением. Подобный фильтр поможет избежать проблем производительности в проектах с относительно большим объёмом данных.

Спасибо за внимание.

С уважением,
Александр Зайцев
/* moderator note: пожалуйста, не используйте подписи на форумах. */

• This reply was modified 5 years, 9 months ago by Yui.
• This reply was modified 5 years, 9 months ago by Yui. Reason: drop signature part