回答这个问题有点晚，但由于它即将用于相关搜索，这将对某些人有用：
WordPress使用EAV数据库模式作为其数据库实现的一部分。这会影响数据和用户。（它们放在单独的表格中）
从数据角度解释：
除了可直接访问的wp\\U帖子中的帖子相关详细信息外，每个帖子都会在wp\\U Posteta表中发布大量元数据。与职位（或自定义职位类型）相关的任何数据。
问题是，如果您有大量的帖子或页面（或自定义帖子/数据），那么搜索meta中的任何属性都会变得非常慢。您首先在元表中搜索所有条目以获得所需的条件，然后从表中获取相关帖子。关键是您需要分别搜索每个条件。因此，一次搜索标记，就可以得到“meta1”的值为X的帖子，然后搜索第二个条件，比如customcriteria，并在customcriteria中获得customcriteriavalue1的帖子ID，然后取这些内容的交集，然后从posts表中获取该交集的帖子详细信息。
例如，将30000个产品放入WooCommerce中，您将在wp\\U Posteta中得到约1800000行，如下面的回答所述：
Post meta vs separate database tables
因此，这不仅会使搜索效率非常低（尤其是当您在wp\\U Posteta上对多个条件进行自连接时），而且即使查询180万行中的一行也会导致性能下降。
EAV架构缺陷。
因此，对于大量帖子，WordPress db实现使得复杂的搜索速度非常慢。
如果您使用缓存插件，那么运行一个包含数千篇帖子的WordPress站点是完全可行的。你可以走得更远。但搜索将是一个问题。
。。。。。。。。。。。。
用户也一样-wp\\u usermeta也使用相同的EAV格式。因此，如果您有很多用户，并且有很多插件在wp\\u usermeta中存储各种用户数据，那么您将受到相同的性能影响。
更不用说有这么多用户，你可能已经有很多帖子了——除非你的应用程序主要与用户有关（CRM等），并且你选择将用户数据存储在wp\\u usermeta而不是wp\\u postmeta中。（尽管不太可能）。
。。。。。。。。。
有一些插件试图绕过这个问题，比如元加速器。
https://wordpress.org/plugins/meta-accelerator/
这个插件为您选择的任何给定帖子类型获取任何数据，并将它们放在平面表中。这大大加快了搜索速度，也加快了查询任何奇异值的速度。
但这个插件还处于起步阶段。
或者，您可以在服务器中安装ElasticSearch，并使用ElasticPress插件或其他将其集成到WordPress的插件来加速此类搜索。
