如何优化WP Query中日期及日期范围匹配的查询性能？

你当前查询效率低的核心原因有4点：

• 多次JOIN wp_postmeta表：现有查询为匹配3个自定义字段连续3次内连接postmeta表，数据量上涨后笛卡尔积效应会急剧放大查询开销
• 字段类型转换开销：查询中用CAST(meta_value AS DATE)做日期转换，会导致MySQL无法命中meta_value字段的索引，触发全表扫描
• 无效的LIKE匹配：单日期字段this_day存储的是定长日期值，用LIKE做精确匹配没有必要，前缀模糊匹配规则也会降低索引命中概率
• SQL_CALC_FOUND_ROWS冗余开销：WordPress默认开启的分页总行数统计，在万级以上数据量场景下，查询耗时会比单独做COUNT统计高2~10倍

第一步：统一日期字段存储格式 #

首先把所有日期类自定义字段的存储格式统一为YYYYMMDD格式的8位定长字符串/无符号整数，不要存储2022-07-01这类带分隔符的日期格式，也不要存时间戳。这种格式下字符串大小比较的结果和日期先后逻辑完全一致，可以彻底去掉CAST类型转换操作。

注意：如果存量数据是旧格式，需要先跑脚本批量转换为YYYYMMDD格式，否则查询结果会出错。

第二步：修正WP_Query查询参数 #

针对现有查询参数做3个调整：

1. 把this_day字段的compare规则从LIKE改为=，用精确匹配替代模糊匹配
2. 去掉日期范围查询的type => DATE配置，直接用字符串比较匹配YYYYMMDD格式的日期值，避免触发类型转换
3. 关闭SQL_CALC_FOUND_ROWS统计，不需要总页数时直接开启no_found_rows，需要总页数时单独写COUNT查询，性能更高
   优化后的查询代码如下：

// 针对当前自定义查询关闭found_rows统计
add_filter( 'found_posts_query', function($sql, $query) {
    if($query->get('custom_date_filter') === true) {
        $sql = '';
    }
    return $sql;
}, 10, 2 );

$args = array(
    'post_type'         => 'post',
    'post_status'       => 'publish',
    'posts_per_page'    => 20,
    'paged'             => 1,
    'custom_date_filter'=> true, // 标记当前查询，对应上述过滤器
    'no_found_rows'     => true, // 不需要总分页数量时开启
    'meta_query'        => array(
        'relation' => 'OR',
        array(
            'key'     => 'this_day',
            'value'   => $startday, // 传入值必须为YYYYMMDD格式
            'compare' => '=',
            'type'    => 'CHAR'
        ),
        array(
            'relation' => 'AND',
            array(
                'key'     => 'date_start',
                'value'   => $startday, // 原有代码此处传$endday属于逻辑错误，单日期查询应传查询日期值
                'compare' => '<=',
                'type'    => 'CHAR'
            ),
            array(
                'key'     => 'date_end',
                'value'   => $startday,
                'compare' => '>=',
                'type'    => 'CHAR'
            ),
        )
    )
);

第三步：给postmeta表添加联合索引 #

WordPress默认的wp_postmeta表只有post_id、meta_key的单字段索引，无法覆盖当前查询场景，添加如下联合索引可以让查询直接走索引拿到匹配结果，不需要回表扫描，性能可提升10倍以上：

ALTER TABLE wp_postmeta ADD INDEX idx_meta_kv_pid (meta_key, meta_value(8), post_id);

索引中meta_value取前8位做前缀索引，刚好覆盖8位长度的YYYYMMDD日期值，能在保证索引命中效率的同时控制索引体积。

进阶优化（10万篇以上文章量场景推荐） #

如果站点文章量很大，即使加了索引多表JOIN的开销依然偏高，可以选择以下两种方案进一步提速：

• 方案1：在wp_posts表新增this_day、date_start、date_end三个无符号整数字段，把日期值冗余存储到posts主表，查询时直接过滤主表字段，完全不需要JOIN postmeta表，查询效率最高
• 方案2：通过posts_clauses过滤器改写原生SQL，把OR条件拆分为两个独立子查询用UNION合并，避免OR条件导致的索引失效，改写后的核心SQL逻辑如下：

SELECT wp_posts.ID FROM wp_posts 
WHERE post_type = 'post' AND post_status = 'publish'
AND ID IN (
    SELECT post_id FROM wp_postmeta WHERE meta_key = 'this_day' AND meta_value = '20220701'
    UNION
    SELECT m1.post_id FROM wp_postmeta m1 
    INNER JOIN wp_postmeta m2 ON m1.post_id = m2.post_id
    WHERE m1.meta_key = 'date_start' AND m1.meta_value <= '20220701'
    AND m2.meta_key = 'date_end' AND m2.meta_value >= '20220701'
)
ORDER BY wp_posts.post_date DESC LIMIT 0,20

这种写法比原生WP_Query生成的多表JOIN加OR的SQL更容易命中索引，执行效率提升明显。

内容的提问来源于stack exchange，提问作者cRiSs rOcCa