通过postmeta获得帖子的最有效方法

$results = $wpdb->get_results("
    SELECT  p.ID,
        p.post_title,
        pm1.meta_value AS first_field,
        pm2.meta_value AS second_field,
        pm3.meta_value AS third_field
    FROM    $wpdb->posts p LEFT JOIN $wpdb->postmeta pm1 ON (
            pm1.post_id = p.ID  AND
            pm1.meta_key    = 'first_field_key'
        ) LEFT JOIN $wpdb->postmeta pm2 ON (
            pm2.post_id = p.ID  AND
            pm2.meta_key    = 'second_field_key'
        ) LEFT JOIN $wpdb->postmeta pm3 ON (
            pm3.post_id = p.ID  AND
            pm3.meta_key    = 'third_field_key'
        )
    WHERE   post_status = 'publish'
");

#1 楼

除非您通过使用WP_Query参数明确告知不要这样做，否则后元信息会自动存储在内存中以用于标准update_post_meta_cache（和主查询）。

因此，您不应该为此编写自己的查询。

元缓存如何用于常规查询：

如果update_post_meta_cache参数如果WP_Query的值未设置为false，则从数据库中检索帖子后，将调用update_post_caches()函数，该函数又调用update_postmeta_cache()。

update_postmeta_cache()函数是update_meta_cache()的包装器，它本质上调用了一个简单的SELECT，其中包含所有检索到的帖子的ID。这将获取查询中所有帖子的所有postmeta，并将该数据保存在对象缓存中（使用wp_cache_add()）。

执行诸如get_post_custom()之类的操作时，它将首先检查该对象缓存。因此，此时并不需要进行额外的查询来获取帖子元。如果您在WP_Query中获得了帖子，则该元已经在内存中，并且可以直接从那里获取它。

这里的优点比进行复杂的查询要大很多倍，但是最大的好处是来自使用对象缓存。如果您使用诸如XCache或memcached或APC之类的持久性内存缓存解决方案，并且具有可以将对象缓存与其绑定的插件（例如，W3 Total Cache），那么整个对象缓存将存储在快速内存中已经。在这种情况下，检索数据所需的查询为零；它已经在内存中了。持久对象缓存在很多方面都很棒。

换句话说，查询的加载和加载可能比使用适当的查询和简单的持久性内存解决方案要慢。使用正常的WP_Query。节省您一些精力。

附加：update_meta_cache()很聪明，顺便说一句。它不会为已经缓存其元信息的帖子检索元信息。基本上，它不会两次获得相同的元数据。超级高效。

其他附加功能：“为数据库提供尽可能多的工作。” ...不，这是Web。适用不同的规则。通常，如果可行，您总是希望对数据库进行尽可能少的工作。数据库运行缓慢或配置不正确（如果您没有专门配置数据库，则可以押注这是事实）。通常，它们在许多站点之间共享，并且在某种程度上超载。通常，您的Web服务器比数据库更多。通常，您只想尽可能快，简单地从数据库中获取所需的数据，然后使用Web服务器端代码对数据进行排序。当然，作为一般原则，不同情况都是不同的。

#2 楼

我建议使用透视查询。以您的示例为例：

SELECT  p.ID,   
        p.post_title, 
        MAX(CASE WHEN pm1.meta_key = 'first_field' then pm1.meta_value ELSE NULL END) as first_field,
        MAX(CASE WHEN pm1.meta_key = 'second_field' then pm1.meta_value ELSE NULL END) as second_field,
        MAX(CASE WHEN pm1.meta_key = 'third_field' then pm1.meta_value ELSE NULL END) as third_field,

 FROM    wp_posts p LEFT JOIN wp_postmeta pm1 ON ( pm1.post_id = p.ID)                      
GROUP BY
   p.ID,p.post_title

#3 楼

我遇到了一种情况，我也想快速检索大量带有相关元信息的帖子。我需要检索O（2000）帖子。

我使用Otto的建议进行了尝试-对所有帖子运行WP_Query :: query，然后为每个帖子循环运行并运行get_post_custom。平均而言，这大约需要3秒钟。

然后我尝试了Ethan的数据透视查询（尽管我不喜欢手动要求我感兴趣的每个meta_key）。我仍然不得不遍历所有检索到的帖子以反序列化meta_value。平均而言，这大约需要1.3秒。

然后我尝试使用GROUP_CONCAT函数，并找到了最佳结果。这是代码：

global $wpdb;
$wpdb->query('SET SESSION group_concat_max_len = 10000'); // necessary to get more than 1024 characters in the GROUP_CONCAT columns below
$query = "
    SELECT p.*, 
    GROUP_CONCAT(pm.meta_key ORDER BY pm.meta_key DESC SEPARATOR '||') as meta_keys, 
    GROUP_CONCAT(pm.meta_value ORDER BY pm.meta_key DESC SEPARATOR '||') as meta_values 
    FROM $wpdb->posts p 
    LEFT JOIN $wpdb->postmeta pm on pm.post_id = p.ID 
    WHERE p.post_type = 'product' and p.post_status = 'publish' 
    GROUP BY p.ID
";

$products = $wpdb->get_results($query);

// massages the products to have a member ->meta with the unserialized values as expected
function massage($a){
    $a->meta = array_combine(explode('||',$a->meta_keys),array_map('maybe_unserialize',explode('||',$a->meta_values)));
    unset($a->meta_keys);
    unset($a->meta_values);
    return $a;
}

$products = array_map('massage',$products);

平均花费0.7秒。这大约是WP get_post_custom（）解决方案的四分之一，而大约是透视查询解决方案的一半。

也许某人对此感兴趣。

#4 楼

我发现自己处在需要完成此任务以最终从中创建CSV文档的情况下，我最终直接与mysql一起完成了此任务。我的代码将发布表和元表连接起来以检索woocommerce定价信息，以前发布的解决方案要求我在sql中使用表别名才能正常工作。

SELECT p.ID, p.post_title, 
    MAX(CASE WHEN pm1.meta_key = '_price' then pm1.meta_value ELSE NULL END) as price,
    MAX(CASE WHEN pm1.meta_key = '_regular_price' then pm1.meta_value ELSE NULL END) as regular_price,
    MAX(CASE WHEN pm1.meta_key = '_sale_price' then pm1.meta_value ELSE NULL END) as sale_price,
    MAX(CASE WHEN pm1.meta_key = '_sku' then pm1.meta_value ELSE NULL END) as sku
    FROM wp_posts p LEFT JOIN wp_postmeta pm1 ON ( pm1.post_id = p.ID)                 
    WHERE p.post_type in('product', 'product_variation') AND p.post_status = 'publish'
    GROUP BY p.ID, p.post_title

但警告说，woocommerce在我的元表中创建了300K +行，因此它非常大，因此非常慢。

#5 楼

没有SQL版本：

没有SQL即可获取所有帖子及其所有元值（元）：

假设您有一个帖子ID列表，存储为ID之类的东西

$post_ids_list = [584, 21, 1, 4, ...];

现在，如果不使用至少一些SQL，就不可能在1个查询中获取所有帖子和所有元数据。 >因此我们必须执行2个查询（仍然只有2个）：

1。获取所有帖子（使用WP_Query）

 $request = new WP Query([
  'post__in' => $post_ids_list,
  'ignore_sticky_posts' => true, //if you want to ignore the "stickiness"
]);
 

（不要忘了打电话给wp_reset_postdata();如果您之后要进行“循环”;））

2.。更新元缓存

 //don't be confused here: "post" means content type (post X user X ...), NOT post type ;)
update_meta_cache('post', $post_ids_list);
 

要获取元数据，只需使用标准get_post_meta()， @Otto指出：首先查看缓存：)

注意：如果您实际上不需要帖子中的其他数据（例如标题，内容等），则只需做2步即可。： -）

#6 楼

使用解决方案形式trevor并对其进行修改以与嵌套SQL一起使用。
未经测试。

global $wpdb;
$query = "
    SELECT p.*, (select pm.* From $wpdb->postmeta AS pm WHERE pm.post_id = p.ID)
    FROM $wpdb->posts p 
    WHERE p.post_type = 'product' and p.post_status = 'publish' 
";
$products = $wpdb->get_results($query);

#7 楼

我也遇到了多值元字段问题。问题出在WordPress本身。查看wp-includes / meta.php。查找以下行：

$where[$k] = ' (' . $where[$k] . $wpdb->prepare( "CAST($alias.meta_value AS {$meta_type}) {$meta_compare} {$meta_compare_string})", $meta_value );

问题出在CAST语句上。在查询元值时，$ meta_type变量设置为CHAR。我不知道有关将值CAST转换为CHAR会如何影响序列化的字符串的详细信息，但要解决此问题，可以删除强制转换，使SQL看起来像这样：
br />现在，即使可行，您也会对WordPress的内部感到不满，因此其他事情可能会中断，并且如果您需要升级WordPress，这不是永久性的解决方法。

我已修复的方式是复制WordPress生成的SQL以获取所需的元查询，然后编写一些PHP以附加我要查找的meta_values的AND语句，并使用$ wpdb-> get_results（$ sql）作为最终输出。哈克，但行得通。