无处不在的对象缓存
WordPress 试图尽可能地减少数据库查询的数量。
例如,任何时候你得到一个元字段或分类字段,在查询数据库之前,WordPress 会检查它是否已经被查询并存储在缓存中,并从那里返回它而不是查询数据库。
“缓存作业”是通过 WP_Object_Cache
类和 wp_cache_*
函数(是该类方法的包装器。)
缓存所在的位置
默认情况下,“缓存”只不过是一个 PHP 全局变量。 这意味着它在内存中,但也意味着它会在每次请求时消失。
但是,通过 dropins (advanced-cache.php
和/或 object-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);
上面的 2 行代码将最多触发 1 个数据库查询。
事实上,当您查询自定义字段时,该帖子的所有字段都从数据库中检索,通过对象缓存进行缓存,随后的请求从缓存中提取数据,而不是从数据库中提取数据。
分类术语也是如此,WordPress 提取一次分类的所有术语,然后从缓存中返回它们。
对象缓存在 WordPress 中使用非常广泛。 不仅针对帖子、元值和分类法,还针对用户、评论、主题数据……
什么 WP_Query
与这一切有关吗?
当您通过以下方式查询某些帖子时 WP_Query
,默认情况下,WordPress 不仅从数据库中提取它们(如果它们被缓存,则从缓存中提取)而且 更新所有自定义字段和所有分类法的缓存 与拉的帖子相关。
所以当你打电话时,例如, get_the_terms()
或者 get_post_meta()
而循环帖子通过 WP_Query
,您实际上并没有触发任何数据库查询,而是从缓存中提取信息。
很好,不是吗?
嗯,是的,但这是有代价的。
WordPress 在通过以下方式拉取帖子时所做的缓存更新“魔术” WP_Query
发生在 update_meta_cache
对于元和 update_object_term_cache
用于分类法。
如果您查看这些函数的源代码,您会发现 WordPress 在每个函数中只执行一个数据库查询,但也进行了大量处理。 例如,在 update_object_term_cache
有7个嵌套 foreach
…如果您有很多分类法,并且每页的帖子数量很高,那么性能就不是很好。
关于那些 WP_Query
争论,最后
什么 'update_post_meta_cache'
和 'update_post_term_cache'
设置为时执行 false
是为了防止 WordPress 分别更新自定义字段和分类法的缓存。
在这种情况下,第一次查询自定义字段或分类时,会触发数据库查询,并缓存数据。
值得麻烦吗?
和往常一样,答案是 这取决于. 大多数时候将这些值设置为 false
是一个不错的选择,因为它可以防止不必要的处理和不需要的数据库查询,并且无论如何在第一次需要自定义字段/分类术语时都会更新缓存。
但是,如果你要打电话,哪怕是一次, get_post_meta()
在循环期间,你将要调用 get_the_terms()
对于帖子支持的所有(或大多数)分类法,无论如何都会触发缓存更新,并且将这些查询参数设置为可能没有实际好处 false
.
原文链接:https://www.wordpresshy.com/326385