通常,在制作 WordPress 网站时,我仅使用帖子元来扩展自定义帖子,并使用自定义分类法进行基本查询。我理解为什么这是使用每个元的正确方法,元比税收等更贵,但我从来没有真正在 WP 中拥有超出此范围的项目。然而,我正在研究自己的一个想法,我需要它从一开始就运行得绝对完美和优化。我花了几个小时试图弄清楚这个问题,所以来这里寻求第二意见。
我有一个产品帖子类型和另一个接受该产品的服务帖子类型。假设产品尺寸为 20 厘米 x 30 厘米 x 10 厘米,我想匹配所有携带该产品的服务。
我添加了 3 个元字段高度、宽度和深度。然后,我已经到达查询第二个帖子类型的阶段,并决定通过帖子元值查询可能是错误的方法?这是一个例子。
'meta_query'=> array(
'relation' => 'AND',
array(
'key' => '_target_width',
'compare' => '>=',
'value' => get_post_meta( get_the_ID(), '_product_width', true ),
'type' => 'numeric'
),
array(
'key' => '_target_height',
'compare' => '>=',
'value' => get_post_meta( get_the_ID(), '_product_height', true ),
'type' => 'numeric'
),
这样可以吗?我对此心存疑虑,并且一直认为我确实需要使用分类法,因为我不确定是否要对可能存在大量数据的数据运行元查询。
所以我的问题是你将如何进行设置?如果征税,那么我如何为自定义分类法的查询设置键值对?还是我坚持上面的内容?
我可能可以写得更短一些,但试图尽可能详细地解释。
最佳答案
元查询可能是最简单的解决方案,但在性能方面并不是最佳的。如果您的 posts
和 postmeta
表增长,此查询可能会变得非常慢。这是因为对于您创建的每个条件,数据库查询都必须对 postmeta
表进行新的左连接(以将该字段的数据作为查询中的单独列加载),这可以得到 table 大的话速度慢。
我通过尝试在具有多种不同条件的大型数据库中查询用户元的艰难方法学到了这一点。
至于使用分类法 - 我认为性能与此特定情况的后元查询类似。
因此,如果性能是优先考虑的,我建议为服务目标创建一个单独的数据库表,其中包含以下列:
service_id -> foreign key to the service's post ID
target_width
target_height
target_depth
这样做的缺点是您将无法使用默认的 WordPress 帖子查询方法来加载帖子或存储目标大小,但您必须为此创建自定义数据库查询,因此这需要一些使用 mysql 的经验。
如果您选择此选项,您仍然可以对产品帖子使用帖子元,除非您必须按这些字段查询帖子(就像您必须处理服务帖子一样)。
所以,这肯定需要做更多的工作,但这个解决方案在性能方面应该要好得多。
但是,如果创建单独的数据库表不适合您,并且您需要在使用后元和分类法之间进行选择,则需要考虑以下事项:
- 对您的
postmeta
表将增长多少进行一些预测 - 许多插件倾向于将大量数据存储为帖子元,因此,如果您的情况如此,则加载分类法可能会更快 table 小了 - 使用分类法不会像后元那样灵活,因为您需要创建所有可能的大小作为术语。另外,我不认为 WordPress 提供了使用分类法运行诸如
>=
之类的查询的功能,因此您仍然需要创建自定义数据库查询来加载帖子 - 找出哪一个性能更好的最佳方法是创建一个包含大量虚拟数据的数据库,并对两个查询运行一些基准测试,以找出哪一个性能更好。请记住,不同的查询会根据 MySQL 版本的不同而执行不同的操作。
希望这会有所帮助!
关于mysql - Wordpress 元查询与分类查询,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46456390/