对象缓存无处不在
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个数据库查询。
实际上,当您查询自定义字段时,该帖子的所有字段都从数据库中检索出来,通过对象缓存进行缓存,并且随后的请求从缓存中而不是从db中提取数据。
分类学术语也是如此,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
。
wp_reset_postdata()
是要重置global $post
并重置对象缓存?听起来,如果我执行了自定义WP_Query,它将创建一个新的缓存对象,但是将其重置也必须重新查询以获取原始缓存。也许在这个问题的背景下我走得太远了。