【问题标题】:Large number of Custom Taxonomy WordPress freezes database and entire website大量自定义分类 WordPress 冻结数据库和整个网站
【发布时间】:2019-09-14 01:42:26
【问题描述】:

我在我的 WordPress 数据库中导入了 10 万个自定义分类术语。我已经分层导入了 Country -> State -> Cities。这样,我的数据库表术语(20 mb)和分类术语(15mb)变得如此之大,以至于我的整个网站和管理面板都崩溃了,甚至无法加载我网站的单个页面。我也尝试过 elasticPress、Jetpack,但它无法帮助我解决这个问题。基本上我想将至少 5 个国家及其州和城市导入到我的数据库中,因此用户可以使用向下钻取下拉方法选择它的位置。 你能帮帮我吗?我可以缓存这个或如何在不影响 mysql 数据库性能的情况下做到这一点?我可以给你更多关于它的信息。请问有什么问题。谢谢你。 PS:我一直在 CloudWays 上托管我的这个网站

【问题讨论】:

  • 令我震惊的是,如果您希望您的用户深入了解位置数据的层次结构,还有其他方法不会让您的 WP 数据库承受如此大量的条目的负担。您是否考虑过 Google Places API,您可以使用 Google 的 API 即时提取位置信息,然后将用户所做的选择存储为自定义值?
  • 感谢您的建议。但主题的工作方式是它使用向下钻取方法来添加新产品和在前端网站搜索。改变整个结构似乎相当困难。

标签: mysql wordpress performance taxonomy custom-taxonomy


【解决方案1】:

创建一个 REST API 来输出您的帖子,而不是普通的 php。它将更快地加载您的帖子。利用这个 Wordpress 功能register_rest_route()

【讨论】:

    【解决方案2】:

    WP 使用 EAV(实体-属性-值)模式模型。这是相当笨拙的,并且不能很好地扩展到“数千”。

    但是,通过改进 WP 中的“元”模式可以部分修复:http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta

    “真正的”解决方法是设计您自己的带有属性列的架构,而不是间接找到它们。

    没有一个很好的理由让 Country->State->City 成为一个层次结构。具有这 3 列(可能还有其他一些东西)的平面表更快且不那么笨拙。其他分类法可能需要分层存储。您想讨论一个具体的问题吗?

    MySQL 8 有一个新特性:CTE。它们使编写查询以遍历层次结构变得更加容易。

    【讨论】:

      猜你喜欢
      • 2017-08-24
      • 1970-01-01
      • 1970-01-01
      • 2017-06-01
      • 2023-03-29
      • 2018-11-17
      • 2011-06-05
      • 1970-01-01
      • 2013-08-03
      相关资源
      最近更新 更多