如何为数以百万计的帖子优化WP网站

#1 楼

1.在运行WP_Query之前设置查询

试图将数据库查询保持在最低限度时，这似乎是要记住的最重要的事情，因为更改查询的唯一机会当然是在SQL数据库中运行之前。

常规查询
对于常规查询，WordPress使用wp()函数，该函数依次调用$wp->main( $query_vars )。在将条件标签的“ is_变量”传递给WP_Query->get_posts()之前，先对其进行设置，然后将其转换为MySQL数据库查询，最后将其存储在$ wp_query对象中。可以在查询实际在SQL数据库中运行之前对其进行过滤。

pre_get_posts操作与该过程相关，可让您在将查询传递给WP_Query->get_posts()之前对其进行更改。
例如，如果您要过滤查询“特色”类别中的帖子，则可以使用add_action( 'pre_get_posts', 'your_function_name' );并将in_category条件标签包含在your_function_name中。 br />请参阅插件API /操作参考/获取相关职位«WordPress Codex

页面请求
关于页面模板，例如“功能”类别的存档页面，将获得条件标签从pre_get_posts过滤器无法正常工作。例如，您不能使用is_category来检查存档页面，因为WP_Query尚未运行。

相反，您必须使用new WP_Query来更改页面请求的主查询，看起来像这样$query = new WP_Query( 'cat=123' );。这将从一开始就使用适当的参数集运行查询。

请参阅类参考/ WP查询«WordPress Codex

2。保存到数据库

可以使用过滤器wp_insert_post_data，确保仅将与自定义帖子类型相关的$ data返回到wp_insert_post。确保包含条件语句以检查您的自定义帖子类型。插件API /过滤器参考/ wp插入帖子数据«WordPress Codex

此挂钩由wp_insert_post函数调用，当您更新自定义帖子类型时，通常通过保存草稿或发布帖子来由wp_update_post调用。

您必须自己对其进行基准测试，因为我不能亲自谈到减少数据库中更新数据的优化意义。

3。自定义帖子类型会影响性能吗？

以我的经验，自定义帖子类型是用于管理内容的强大工具。我不知道有什么其他方式可以使用更少的资源来以允许的所有方式来管理帖子。我个人将着重于寻找方法，以尽可能地减少进行查询的数量。 number.3这对于承载大量页面的网站特别麻烦，但是自WordPress 3.3版以来已解决。版本3.3之前可能会或可能不会影响性能的永久链接结构。除此之外，我不知道使用自定义帖子类型会引起任何性能问题。

其他性能选项

瞬态
这不能代替将查询保持在代码最少的状态，但是您可以使用set_transient存储查询以用于需要一些时间，因此不需要新的查询。这是Dave Clements帖子中使用的示例。另外，请注意，他建议添加save_post操作以在更新给定帖子类型时删除瞬态。他的“优化WordPress查询”教程中的一些好技巧。以下是他的建议的简要列表：



如果服务器是服务器，请在一次性查询中设置'cache_results' => false
不使用持久缓存，例如Memcached。一次性查询被描述为“用于显示少量数据的查询。
您可能只想显示与当前帖子相关的链接帖子标题，或者您可能想显示要为特定选项设置选择
的帖子的下拉列表。”

他的示例：$query = get_posts( array( 'posts_per_page' => 1, 'cache_results' => false ) );


在不需要分页的地方设置'no_found_rows' => true。这
“将绕过MySQL计数结果以查看是否需要分页”。

他的示例：$query = new WP_Query( array( 'posts_per_page' => 1, 'no_found_rows' => true ) );


仅在您需要'fields' => 'ids'
的情况下，才查询帖子ID。这样可以大大减少返回的数据量，如果您查看
数据库描述«WordPress
Codex

他的示例： get_posts


除了最后一个技巧，使用get_post_field仅需要一个或几个post字段时，可以应用相同的推理。扎实的了解查询的工作原理至关重要。查询越具体，对SQL数据库的要求就越少。这意味着管理数据库查询存在多种可能性。在自定义查询的运行位置（这是一个管理页面？）要小心，在直接查询中使用适当的清理方法，并尝试使用本机WordPress函数在其中实现相同的性能。

#2 楼

我还添加：

    'no_found_rows'          => true,
    'update_post_term_cache' => false,
    'update_post_meta_cache' => false,
    'cache_results'          => false

no_found_rows（布尔值）–当您不需要任何分页并且不需要时，请使其正确
cache_results（布尔值）–帖子信息缓存。
update_post_meta_cache（布尔值）–帖子元信息缓存。

通过使用这些参数并将值作为FALSE传递，我们可以通过停止执行一些额外的数据库查询来使
查询更快。

注意：我们不应该总是使用这些参数，因为在缓存中添加内容是正确的选择，但是在特定情况下它们可能很有用，因此当您知道自己在做什么时，应该考虑使用。


请访问：
https://drujoopress.wordpress.com/2013/06/27/how-to-optimize-wordpress-query-to-get-results -faster /＃more-184

#3 楼

由于所有过早的优化类型的问题都无法在不知道确切的使用模式的情况下真正回答，只有在您上线时才会被发现太多次。数据量有任何问题。当然，即使使用最佳算法，也比使用较小的表搜索数据慢，但是解决方案是简单，强大的CPU。

您可能想优化元数据的存储方式（例如而不是存储与ping相关的数据），但这取决于您的工作方式，最终您可能仍需要更强大的CPU，因此可能不值得麻烦。