update_post_（meta / term）_cache的说明

#1 楼

对象缓存随处可见

WordPress尝试尽可能减少数据库查询的数量。

例如，在查询元数据或分类法字段之前，只要在数据库中，WordPress查找是否已查询并存储在缓存中的内容，然后从那里返回而不是查询数据库。

“缓存作业”是通过WP_Object_Cache类和wp_cache_*函数（即类方法的包装器。）

缓存所在的位置

默认情况下，“缓存”不过是PHP全局变量。这意味着它在内存中，但也意味着它在每次请求时都消失。 。

通常，此dropins用于设置某种缓存机制，以“保留”单个请求。

因此，在WP人员中，这些被称为“持久性缓存”插件（即使在气泡之外，“缓存”和“持久性”一词并没有多大意义）。

如今，流行的选择是Memcached或Redis。

因此，使用“持久性缓存”插件可以极大地减少数据库查询的数量，因为不会在每个请求上都更新缓存。

一些示例

$foo = get_post_meta('foo', $post_id, true);
// a lot of code in the middle
$bar = get_post_meta('bar', $post_id, true);

上面的两行代码最多将触发1个数据库查询。

实际上，当您查询自定义字段时，该帖子的所有字段都从数据库中检索出来，通过对象缓存进行缓存，随后的请求从缓存而不是从数据库中提取数据。

发生分类术语时，WordPress会一次提取所有分类术语，然后从缓存中返回它们。

对象缓存在WordPress中使用非常广泛。不仅对于帖子，元值和分类法，而且对于用户，评论，主题数据...

advanced-cache.php与所有这些都有什么关系？

当您通过object-cache.php查询某些帖子时，默认情况下，WordPress不仅将它们从数据库中拉出（或从缓存（如果已缓存）中拉出），还会更新所有自定义字段和与拉出的帖子相关的所有分类法的缓存。

因此，当您循环调用通过WP_Query获得的帖子时，例如调用WP_Query或get_the_terms()时，实际上并不会触发任何数据库查询，而是从缓存中提取信息。

很好，不是t？

好吧，是的，但是要付出一定的代价。

当通过get_post_meta()进行拉动发布时，WordPress在meta和in中通过WP_Query提取信息时，缓存所做的“魔术”更新如果您查看这些函数的源代码，则会发现WordPress在每个函数中仅执行一个db查询，但也进行了大量处理。例如，在WP_Query中有7个嵌套的update_meta_cache ...如果您有大量的分类法，并且每页的帖子数很高，则效果不是很好。

关于这些update_object_term_cache的参数，最后

将update_object_term_cache和foreach设置为WP_Query时的作用是防止WordPress分别更新自定义字段和分类法的缓存。

在这种情况下，第一次查询自定义字段或分类法时，将触发数据库查询，并缓存数据。

值得吗？

通常，答案取决于情况。在大多数情况下，将这些值设置为'update_post_meta_cache'是一个不错的选择，因为它可以防止不必要的处理和数据库查询（如果不需要的话），并且无论如何在第一次需要自定义字段/分类法术语时都会更新缓存。

但是，如果您要在循环中调用'update_post_term_cache'，甚至要调用一次，并且要为帖子支持的所有（或大多数）分类法调用false，则无论如何都会触发缓存更新，并且可能将这些查询参数设置为false并没有实际好处。

#2 楼

这里的主要关注点是update_post_caches函数。在WP_Query从数据库获取所有帖子之后调用它。通常，您首先要显示帖子的原因是要显示它们，这通常意味着要显示基于元数据的术语和内容，因此WP_Query还将默认在数据库中查询与返回的帖子相关的元数据和术语数据并将其存储在缓存中*。从WP_Query返回的数据中没有明确提供此信息，但是当您调用相关API来获取特定帖子的字词和元信息时，该信息已经在内存中可用，因此无需发送新的查询到数据库。

这使wordpress通过仅发送一个请求以获取所有帖子的信息，而不是每个帖子都发送一个请求，从而减少了与向DB发送请求相关的开销。

现在，我找不到任何不平凡的例子说明何时不希望更新缓存，但是如果您只想列出所有帖子的标题，则可能是一个不重要的例子。为此，您不需要术语或元数据。

* cache-最重要的是基于内存的缓存，其中WP将从数据库获取的所有内容存储到almot，即使没有任何对象缓存插件处于活动状态。显然，当您有对象缓存时，信息也将存储在其中。