magento中的索引如何工作

1. Magento中的索引工作原理
2. 它到底是做什么的？
3. 为什么需要它？

Magento中有不同类型的索引。
所有索引器都可以使运行速度更快。
我将在这里仅介绍其中的一些。

固定索引
有2个这样的索引。一种用于类别，一种用于产品。
默认情况下，类别和产品实体（以及客户和客户地址，但在这种情况下并不重要）是EAV实体。这对于扩展性非常好。但这是性能杀手，因为要获取所有属性的所有值，您需要大量的联接或多个查询。
这是平面索引器起作用的地方。
它将EAV结构转换为平面结构。我的意思是，它创建了一个表（Magento中每个商店视图一个表），该表具有对应于属性的一列。这使选择更快。对于类别，所有属性都转换为表列。对于产品，只有那些您标记为“用于产品清单”的产品，因为您可以出售具有不同属性的所有类型的产品，并且可能无法创建一个包含数以百万计的列的表格。
另外，某些产品可能已禁用或可能不属于某个网站，因此无需在搜索条目中包括它们。它们被索引器排除。
生成的平面表用于读取前端的数据。后端仍使用EAV结构。

目录搜索索引
您可以通过许多属性值搜索产品。其中一些可能未包含在平面索引器生成的平面表中。该索引使用产品的可搜索属性值填充表格，因此更容易根据关键字查找它们。将所有信息都放在一个表（或一个字段）中，可以使用全文本搜索并获得相关结果。

产品价格。
产品的价格可能受许多变量影响。例如，客户组，网站，目录折扣规则。
与上述相同，以价格获得产品将意味着大量的加入或多项选择。此外，捆绑销售产品具有奇怪的定价系统。该索引器将数据汇总到某些表（catalog_product_index_price_*）中，并使选择（排序和过滤）更加容易。

目录url重写
通过设置哪个url对应于哪个产品或类别来清理url重写规则。通过这种方式，URL管理内部系统可以更轻松地确定在调用非标准URL时应查看哪个页面。无需搜索所有产品和类别URL关键字，而是仅在一个表中搜索。

类别产品
在Magento中，您可以将名为“ Is Anchor”的类别属性设置为true或false。如果为真，则表示相关类别将列出其子类别中的所有产品。同样，确定这种实时性将需要比仅读取一张表更多的资源。该索引器根据您在后端中设置的关联以及类别上的“ Is Anchor”标志创建产品和类别之间的关联。

库存状态
对于简单产品，这很容易。它们可以有库存，也可以无货，但是对于可配置，分组和捆绑而言，并不是那么容易。根据与主要产品关联的子产品，它们可能有现货或无现货。再次（我只是在这里重复我自己），实时获取其状态将意味着很多查询。

产品属性。
出于相同的原因，这收集了所有可以在分层导航中使用的属性。将所有这些文件放在一个地方，以便快速阅读。

标签聚合
我不知道这是做什么的。我从未在实际的实时项目中使用过标签。

无法取信，因为它取自原始帖子：https : //stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail

本质上，Magento的索引编制仅类似于数据库级索引编制。正如安东所说，这是一种非规范化的过程，可以使站点更快地运行。让我尝试解释一下Magento数据库结构背后的一些想法，以及为什么它使索引必须快速运行。

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

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

这种方法检索起来很快，但是对于一个电子商务软件来说却存在一个基本问题：当您想添加更多属性时该怎么办？如果您销售玩具，而不是size列，那么需要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中输入新值，然后将相邻记录放入product_attribute_values中，随意添加属性。基本上，这就是Magento所做的（对数据类型的尊重比我在这里显示的要多一些）。实际上，现在完全没有理由两个产品都具有相同的字段，因此我们可以创建具有不同属性集的整个产品类型！

但是，这种灵活性是有代价的。如果要在系统中查找衬衫的颜色（一个简单的示例），则需要查找：

1. 商品的product_id（在商品表中）
2. 颜色的attribute_id（在属性表中）
3. 最后，实际值（在attribute_values表中）

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

这些结果查询表是Magento的“索引”。重新索引时，您正在炸毁旧表并再次生成它。

希望能使事情澄清一下！

Magento是一个非常强大且复杂的系统。它允许处理大量数据，但是当数据库中有成千上万条记录超载时，它将变得繁重而缓慢。Magento使用索引来解决此问题。索引是带有一些平面数据的其他数据库表，它可以组织来自数据库的快速响应。

默认情况下，核心系统会更新每个项目的保存上的索引。但是在某些情况下，您需要手动执行操作，例如某些类型的大规模操作等。您可以随时从admin后端（Admin-> System-> Index Management）更新索引。但是有时会引起问题。

例如，如果您有10k +产品和很多类别，则重建“目录url重写”索引可能需要几个小时。然后，PHP脚本可能会因为max_execution_time超出而中断。有一种方法可以通过从命令行运行重新索引过程来解决一些问题。