当前位置：文江博客话题详情

有人可以详细解释 Magentos 索引功能吗？

发布于 2024-10-16 11:59:46 字数 456 浏览 2 评论 0原文

我有点了解 Magento 中的索引是如何工作的，但我还没有看到任何关于这方面的好的文档。我想了解以下内容。

它是如何工作的
它的目的是什么
为什么它很重要
每个人都应该了解它的详细信息
任何其他可以帮助人们完全理解什么是索引以及它如何在 Magento 中使用的

信息我认为拥有这些信息对其他人将非常有用在我的船上，没有完全完成索引过程。

更新：在对我的问题和 Ankur 的回答进行评论之后，我想我在正常数据库索引的知识中遗漏了一些东西。那么这只是 Magento 处理索引的版本吗？对我来说，在一般数据库索引方面得到答案是否更好，例如这里的链接数据库索引如何工作？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

白馒头 2024-10-23 11:59:46

Magento 的索引只是在精神上类似于数据库级索引。正如安东所说，这是一个非规范化的过程，以允许站点更快地运行。让我尝试解释 Magento 数据库结构背后的一些想法以及为什么它需要索引才能快速运行。

在更“典型”的 MySQL 数据库中，用于存储目录产品的表的结构如下：

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

这对于检索来说速度很快，但它为电子商务软件留下了一个基本问题：当您想要添加时该怎么办更多属性？如果您销售玩具，并且需要 age_range 而不是尺寸列，该怎么办？好吧，您可以添加另一列，但应该清楚的是，在大型商店（例如沃尔玛）中，这将导致 90% 的行为空，并且尝试维护新属性几乎是不可能的。

为了解决这个问题，Magento 将表分成更小的单元。我不想在这个答案中重新创建整个 EAV 系统，所以请接受这个简化的模型：

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

现在可以通过在 product_attributes 中输入新值，然后将相邻记录放入 <代码>产品属性值。这基本上就是 Magento 所做的（比我在这里展示的更尊重数据类型）。事实上，现在两个产品根本没有理由具有相同的字段，因此我们可以创建具有不同属性集的整个产品类型！

然而，这种灵活性是有代价的。如果我想在我的系统中查找衬衫的 color（一个简单的示例），我需要查找：

的 product_id（在产品表中）
该商品 attribute_id for color（在属性表中）
最后，实际的value（在attribute_values表中）

Magento过去是这样工作的，但它速度太慢了。因此，为了获得更好的性能，他们做出了妥协：一旦店主定义了他们想要的属性，就从头开始生成大表。当某些事情发生变化时，将其从太空中发射出来并重新生成。这样，数据主要以我们灵活的格式存储，但从单个表中查询。

这些生成的查找表是 Magento“索引”。当您重新索引时，您将破坏旧表并重新生成它。

希望能澄清一些事情！

谢谢，
乔

Magento's indexing is only similar to database-level indexing in spirit. As Anton states, it is a process of denormalization to allow faster operation of a site. Let me try to explain some of the thoughts behind the Magento database structure and why it makes indexing necessary to operate at speed.

In a more "typical" MySQL database, a table for storing catalog products would be structured something like this:

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

This is fast for retrieval, but it leaves a fundamental problem for a piece of eCommerce software: what do you do when you want to add more attributes? What if you sell toys, and rather than a size column, you need age_range? Well, you could add another column, but it should be clear that in a large store (think Walmart, for instance), this would result in rows that are 90% empty and attempting to maintenance new attributes is nigh impossible.

To combat this problem, Magento splits tables into smaller units. I don't want to recreate the entire EAV system in this answer, so please accept this simplified model:

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

Now it's possible to add attributes at will by entering new values into product_attributes and then putting adjoining records into product_attribute_values. This is basically what Magento does (with a little more respect for datatypes than I've displayed here). In fact, now there's no reason for two products to have identical fields at all, so we can create entire product types with different sets of attributes!

However, this flexibility comes at a cost. If I want to find the color of a shirt in my system (a trivial example), I need to find:

The product_id of the item (in the product table)
The attribute_id for color (in the attribute table)
Finally, the actual value (in the attribute_values table)

Magento used to work like this, but it was dead slow. So, to allow better performance, they made a compromise: once the shop owner has defined the attributes they want, go ahead and generate the big table from the beginning. When something changes, nuke it from space and generate it over again. That way, data is stored primarily in our nice flexible format, but queried from a single table.

These resulting lookup tables are the Magento "indexes". When you re-index, you are blowing up the old table and generating it again.

Hope that clarifies things a bit!

Thanks,
Joe

回复收藏 0 原文