我在自定义meta中使用了许多自定义帖子类型(CPT),到目前为止,我一直在使用如下查询,以获取2014年CountryX中发生的所有事件:
<?php
global $paged;
$curpage = $paged ? $paged : 1;
$args = array(
\'numberposts\' => -1,
\'post_type\' => \'event\',
\'orderby\' => \'event_date\',
\'meta_key\' => \'event_date\',
\'order\' => \'DES\',
\'posts_per_page\' => 50,
\'paged\' => $paged,
\'meta_query\' => array(
\'relation\' => \'AND\',
array(
\'key\' => \'event_date\',
\'compare\' => \'<=\',
\'value\' => 20141231,
),
array(
\'key\' => \'event_date\',
\'compare\' => \'>=\',
\'value\' => 20140101,
),
array(
\'key\' => \'event_country\',
\'compare\' => \'LIKE\',
\'value\' => \'CountryX\',
),
),
);
$the_query = new WP_Query( $args );
我担心这类查询所需的时间、RAM和CPU进程,因此我开始阅读有关自定义SQL查询的内容(
https://codex.wordpress.org/Displaying_Posts_Using_a_Custom_Select_Query).
我仍然不清楚切换到自定义查询是否会提高速度,或者在我的情况下没有任何改进。
此外,由于我刚刚开始使用SQL,如果您能帮助我开始编写上述查询(使用多个条件语句),我将不胜感激。
edit: 当我们使用它时LIKE
查询具有文本和/或数组的自定义元字段是一个好主意?
提前感谢
SO网友:Pieter Goosen
通常,不管怎样,自定义SQL查询都比WordPress本机功能快。真正的问题是,这些自定义SQL查询是否更好,简单的答案是“否”。让我们看看为什么不使用自定义SQL查询的几个要点:
如果出现以下情况,请松开所有过滤器WP_Query
, 你松开了pre_get_posts
以及posts_*
过滤器
维护SQL查询是一项艰巨的任务。WordPress是一个正在进行的项目,不断进行的更改也会影响数据库。这可能会对SQL查询产生负面影响,并可能导致不必要的调试工作。函数和类,如WP_Query
和get_post_meta()
它使用SQL查询,用db维护功能是由核心开发人员完成的,所以他们要做艰苦的工作。当您更新到对db进行了更改的版本时,您甚至没有注意到查询中的任何内容
更改SQL查询通常需要完全重写,如果您对SQL语法没有信心,可能会导致其他问题。像这样的班级WP_Query
, 您只需根据需要从参数数组中添加/删除参数即可
您失去了完整的内置对象缓存系统,该系统用于存储post等数据及其相关post数据,以避免不断的db调用。实现该缓存系统是为了提高查询的性能
meta_query
\'s总是比任何普通查询都慢,因为它涉及表的连接,并且变量数组的嵌套程度越高,查询的速度就越慢,这适用于普通SQL查询和WP_Query
呼叫。使用的优点WP_Query
但是,第一次运行查询时,可能会很慢,因为数据库会受到重击以获取与查询匹配的帖子,但一旦运行查询,并且所有内容都保存在帖子对象缓存中,第二次运行查询时,就会从缓存中检索帖子,而不是从数据库中检索帖子
但是,您可以使用瞬态存储自定义查询,并每周或每月或在需要时刷新一次瞬态。这将极大地提高性能,因为查询只会在重建瞬态时运行。如果使用transition_post_status
钩如果您需要在更新post meta时刷新瞬态,您可以查看如下操作updated_post_meta
. Here 这是一篇很好的帖子。
对于编辑,不要将自定义字段值存储为数组。不幸的是,如果您想要在自定义字段中排序或搜索特定值,它将无法处理序列化数据。存储单个字符串值。而且LIKE
也是不需要的,因为如果您搜索dot
, 像这样的词dot
, dotcom
, 和mydot
将全部匹配,这将从您的查询中得到不需要的结果