探究 WordPress `get_adjacent_post()` 函数的源码：如何查询相邻文章的 ID，并解释其性能。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷，晚上好！欢迎来到“WordPress 源码扒皮”系列讲座，我是今天的主讲人，老码。今天我们要聊的是 WordPress 里一个看似简单，实则暗藏玄机的函数：get_adjacent_post()。别看它名字平平无奇，作用也好像只是获取相邻的文章，但它背后的逻辑和性能优化，可是有不少值得我们探讨的地方。

开场白：get_adjacent_post() 是个啥？

简单来说，get_adjacent_post() 函数用于获取与当前文章相邻（前一篇或后一篇）的文章对象。它的基本用法如下：

<?php
$previous_post = get_adjacent_post( false, '', true ); // 获取前一篇文章
$next_post = get_adjacent_post( false, '', false ); // 获取后一篇文章
?>

参数说明：

$in_same_term (bool, 可选): 是否只在同一分类/标签下查找。默认为 false。
$excluded_terms (string|array, 可选): 要排除的分类/标签 ID 或 slug，多个用逗号分隔或以数组形式传递。默认为空字符串。
$previous (bool, 可选): true 获取前一篇，false 获取后一篇。默认为 true。
$taxonomy (string, 可选): 如果 $in_same_term 为 true，则指定分类法 (taxonomy)。默认为 ‘category’。

源码解读：一层一层扒开它的心

好了，废话不多说，直接上代码，让我们一起看看 get_adjacent_post() 的源码 (位于 wp-includes/link-template.php 文件中)。

function get_adjacent_post( $in_same_term = false, $excluded_terms = '', $previous = true, $taxonomy = 'category' ) {
    global $post, $wpdb;

    if ( empty( $post ) ) {
        return null;
    }

    $current_post_date = $post->post_date;

    $op = $previous ? '<' : '>';
    $order = $previous ? 'DESC' : 'ASC';
    $date_query_compare = $previous ? '<' : '>';

    $join = '';
    $where = '';

    if ( $in_same_term ) {
        $term_object = get_the_terms( $post, $taxonomy );

        if ( is_wp_error( $term_object ) || empty( $term_object ) ) {
            return null;
        }

        $term_ids = wp_list_pluck( $term_object, 'term_id' );

        $join = " INNER JOIN {$wpdb->term_relationships} AS tr ON p.ID = tr.object_id INNER JOIN {$wpdb->term_taxonomy} AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id";
        $where = $wpdb->prepare( "AND tt.taxonomy = %s AND tt.term_id IN (" . implode( ',', array_fill( 0, count( $term_ids ), '%d' ) ) . ")", array_merge( array( $taxonomy ), $term_ids ) );
    }

    if ( ! empty( $excluded_terms ) ) {
        if ( is_array( $excluded_terms ) ) {
            $excluded_terms = implode( ',', $excluded_terms );
        }
        $join .= " INNER JOIN {$wpdb->term_relationships} AS tr2 ON p.ID = tr2.object_id INNER JOIN {$wpdb->term_taxonomy} AS tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id";
        $where .= " AND tt2.term_id NOT IN (" . $excluded_terms . ")";
    }

    $where .= $wpdb->prepare( " AND p.post_type = %s AND p.post_status = 'publish' AND p.post_date $date_query_compare %s", $post->post_type, $current_post_date );

    $sort  = "ORDER BY p.post_date $order LIMIT 1";
    $query = "SELECT p.* FROM {$wpdb->posts} AS p $join WHERE 1=1 $where $sort";
    $query = apply_filters( 'get_adjacent_post_where', $query );
    $query = apply_filters( 'get_adjacent_post_sort', $query );

    $adjacent_post = $wpdb->get_row( $query );

    if ( ! empty( $adjacent_post ) ) {
        $adjacent_post = sanitize_post( $adjacent_post );
    }

    /**
     * Filters the adjacent post.
     *
     * @since 1.5.0
     *
     * @param WP_Post|null $adjacent_post The adjacent post, or null if none found.
     * @param bool         $in_same_term  Whether post should be in a same term.
     * @param string|array $excluded_terms Array or comma-separated string of excluded term IDs.
     * @param bool         $previous      Whether to retrieve the previous post.
     * @param string       $taxonomy      Taxonomy to use when determining term relationship.
     */
    return apply_filters( 'get_adjacent_post', $adjacent_post, $in_same_term, $excluded_terms, $previous, $taxonomy );
}

现在，我们一行一行地拆解这段代码，看看它到底做了些什么：

参数检查与初始化:
- 首先，函数会检查全局变量 $post 是否为空。如果为空，说明当前上下文中没有文章信息，直接返回 null。
- 然后，获取当前文章的发布时间 $current_post_date，用于后续的日期比较。
- 根据 $previous 参数，设置比较运算符 $op 和排序方式 $order。如果 $previous 为 true，则 $op 为 ‘<‘ (小于)，$order 为 ‘DESC’ (降序)，表示查找前一篇；否则 $op 为 ‘>’ (大于)，$order 为 ‘ASC’ (升序)，表示查找后一篇。
- 初始化 $join 和 $where 变量，用于构建 SQL 查询语句。
处理同分类/标签下的相邻文章:
- 如果 $in_same_term 为 true，表示需要在同一分类/标签下查找相邻文章。
- 首先，使用 get_the_terms() 函数获取当前文章所属的分类/标签对象。
- 如果获取失败或为空，直接返回 null。
- 然后，使用 wp_list_pluck() 函数提取分类/标签对象的 ID，并构建 SQL 的 JOIN 和 WHERE 子句，用于限制查询结果。
- 这里用到了implode( ',', array_fill( 0, count( $term_ids ), '%d' ) )，这个小技巧是为了生成占位符，防止SQL注入。
处理排除的分类/标签:
- 如果 $excluded_terms 不为空，表示需要排除某些分类/标签下的文章。
- 将 $excluded_terms 转换为字符串，并构建 SQL 的 JOIN 和 WHERE 子句，用于排除查询结果。
构建 SQL 查询语句:
- 使用 $wpdb->prepare() 函数构建 SQL 的 WHERE 子句，限制查询结果为已发布的文章，并且发布时间早于/晚于当前文章。
- 构建 SQL 的 ORDER BY 子句，按照发布时间排序，并使用 LIMIT 1 限制只返回一条结果。
- 将所有 SQL 子句拼接成完整的 SQL 查询语句。
执行查询并返回结果:
- 使用 $wpdb->get_row() 函数执行 SQL 查询，获取相邻文章的对象。
- 如果查询结果不为空，使用 sanitize_post() 函数对文章对象进行安全过滤。
- 使用 apply_filters() 函数应用 get_adjacent_post 过滤器，允许开发者修改返回结果。
- 最终返回相邻文章的对象。

性能分析：魔鬼藏在细节里

好了，代码我们已经扒了个底朝天，现在让我们来聊聊性能。 get_adjacent_post() 函数的性能瓶颈主要在于 SQL 查询。尤其是在以下情况下，性能可能会受到影响：

$in_same_term 为 true: 当需要在同一分类/标签下查找相邻文章时，需要执行 JOIN 操作，连接 wp_posts、wp_term_relationships 和 wp_term_taxonomy 三个表。如果文章数量巨大，或者分类/标签数量众多，这个 JOIN 操作可能会非常耗时。
$excluded_terms 不为空: 排除分类/标签也会导致 JOIN 操作，进一步增加查询复杂度。
没有合适的索引: 如果 wp_posts 表的 post_date 字段没有索引，或者 wp_term_relationships 和 wp_term_taxonomy 表的相关字段没有索引，SQL 查询可能会执行全表扫描，导致性能急剧下降。

为了更直观地说明性能问题，我们来看几个具体的 SQL 查询示例：

示例 1：获取前一篇文章 (不限制分类/标签)

SELECT p.*
FROM wp_posts AS p
WHERE 1=1
  AND p.post_type = 'post'
  AND p.post_status = 'publish'
  AND p.post_date < '2023-10-27 20:00:00'
ORDER BY p.post_date DESC
LIMIT 1

这个查询相对简单，只需要查询 wp_posts 表，并且假设 post_date 字段有索引，性能应该比较好。

示例 2：获取前一篇文章 (限制在同一分类下)

SELECT p.*
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 1=1
  AND tt.taxonomy = 'category'
  AND tt.term_id IN (1, 2, 3)
  AND p.post_type = 'post'
  AND p.post_status = 'publish'
  AND p.post_date < '2023-10-27 20:00:00'
ORDER BY p.post_date DESC
LIMIT 1

这个查询需要连接三个表，并且 WHERE 子句中包含了多个条件，性能会受到一定影响。

示例 3：获取前一篇文章 (限制在同一分类下，并排除某些分类)

SELECT p.*
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
INNER JOIN wp_term_relationships AS tr2 ON p.ID = tr2.object_id
INNER JOIN wp_term_taxonomy AS tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id
WHERE 1=1
  AND tt.taxonomy = 'category'
  AND tt.term_id IN (1, 2, 3)
  AND tt2.term_id NOT IN (4, 5)
  AND p.post_type = 'post'
  AND p.post_status = 'publish'
  AND p.post_date < '2023-10-27 20:00:00'
ORDER BY p.post_date DESC
LIMIT 1

这个查询的复杂度最高，连接了四个表，并且 WHERE 子句中包含了多个条件，性能可能会非常差。

为了更清晰地总结性能影响因素，我们可以用表格来展示：

参数组合	性能影响	优化建议
`$in_same_term = false`, `$excluded_terms` 为空	最佳	确保 `wp_posts` 表的 `post_date` 字段有索引。
`$in_same_term = true`	中等	确保 `wp_term_relationships` 和 `wp_term_taxonomy` 表的相关字段有索引。考虑使用缓存插件，缓存查询结果。
`$excluded_terms` 不为空	中等	确保 `wp_term_relationships` 和 `wp_term_taxonomy` 表的相关字段有索引。考虑减少需要排除的分类/标签数量。
`$in_same_term = true`, `$excluded_terms` 不为空	最差	尽量避免同时使用这两个参数。如果必须使用，请确保所有相关字段都有索引，并使用缓存插件。考虑重构代码，使用更高效的查询方式，例如自定义 SQL 查询。

优化技巧：让它跑得更快！

既然我们知道了性能瓶颈在哪里，就可以对症下药，采取一些优化措施：

索引优化: 确保 wp_posts 表的 post_date 字段，以及 wp_term_relationships 和 wp_term_taxonomy 表的相关字段都有索引。索引就像书的目录，可以帮助数据库快速找到所需的数据，避免全表扫描。
缓存: 使用 WordPress 缓存插件 (例如 WP Super Cache, W3 Total Cache) 可以缓存 get_adjacent_post() 函数的查询结果，避免重复查询数据库。
自定义 SQL 查询: 如果 get_adjacent_post() 函数的性能无法满足需求，可以考虑使用自定义 SQL 查询来获取相邻文章。自定义 SQL 查询可以更灵活地控制查询逻辑，从而提高查询效率。例如，可以使用子查询或临时表来优化查询。
重新审视需求: 有时候，性能问题并不是代码本身造成的，而是需求不合理。例如，是否真的需要限制在同一分类/标签下查找相邻文章？是否可以减少需要排除的分类/标签数量？重新审视需求，可以从根本上解决性能问题。

总结：get_adjacent_post()，小函数，大智慧

好了，今天的讲座就到这里。通过对 get_adjacent_post() 函数源码的解读和性能分析，我们不仅了解了它的实现原理，还学习了一些性能优化的技巧。希望今天的分享对大家有所帮助。

记住，即使是一个看似简单的函数，背后也可能隐藏着复杂的逻辑和性能问题。作为一名优秀的开发者，我们不仅要会使用这些函数，更要了解它们的原理，才能写出高效、健壮的代码。

感谢大家的收听，我们下期再见！各位观众老爷，打赏点赞走一波！

发表回复 取消回复

发表回复取消回复