索引何时失效?


23

我有一家商店,所有时间所有索引均无效。我注意到索引无效时我不知道。

您能给我一个“所有”事件的列表,这些事件使一个或多个这些索引无效吗?

  • 产品属性
  • 产品价格
  • 目录URL重写
  • 产品平面数据
  • 分类产品
  • 目录搜索索引
  • 标签汇总数据
  • 库存状况

Answers:


18

在代码目录上执行grep将获得触发失效的文件列表。 grep -Ri '::STATUS_REQUIRE_REINDEX' .

以下核心文件触发无效

./core/Mage/CatalogSearch/Model/Indexer/Fulltext.php
./core/Mage/Catalog/Model/Product/Indexer/Flat.php
./core/Mage/Catalog/Model/Product/Indexer/Price.php
./core/Mage/Catalog/Model/Category/Indexer/Flat.php
./core/Mage/Catalog/Model/Category/Indexer/Product.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Product/Flat.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Category/Flat.php
./core/Mage/Catalog/Model/Indexer/Url.php
./core/Mage/Backup/Helper/Data.php
./core/Mage/CatalogInventory/Model/Indexer/Stock.php
./core/Mage/ImportExport/Model/Import.php

Magento CE核心中的基本事件是

产品属性

如果启用了平面目录产品,则特定的保存属性(属于平面产品的一部分),store,store_group

产品价格

检查配置设置是否保存(如价格范围)。或产品保存,网站创建/删除

目录URL重写

没有具体的无效

产品平面数据

特定的保存属性(属于平面产品),如果启用了平面目录产品,则在启用平面产品之后

类别平面数据

检查是否启用了平面类别和特定的保存类别,启用平面类别之后

分类产品

检查是否启用了平面目录类别并指定了保存类别

目录搜索索引

如果启用了平面目录产品,则特定的保存属性(属于可搜索属性),store,store_group

标签汇总数据

除以下提到的一般条件外,从未失效

库存状况

库存选项卡中保存特定的系统>配置设置,例如显示缺货的产品

在从System > Tools > Backup网站,商店和商店视图以及在网站,商店和商店视图上进行备份回滚以及回退备份后,所有这些元素都将无效。

通过保存core_config_data值,一些索引器(如平面数据和URL索引器)似乎也会失效。


14

暂时在此站点上临时创建重写是一个主意

Mage_Index_Model_Resource_Process

然后执行以下操作:

<?php

class YourNamespace_YourModule_Model_Resource_Process
    extends Mage_Index_Model_Resource_Process
{

    public function updateStatus($process, $status)
    {
        if ($status === Mage_Index_Model_Process::STATUS_REQUIRE_REINDEX) {
            Mage::log(sprintf('Indexer %s was invalidated.', $process->getIndexer()->getName()), null, 'invalid_index.log', true);
            foreach (debug_backtrace() as $db) {
                Mage::log(sprintf('%s::%s', $db['class'], $db['function']), null, 'invalid_index.log', true);
            }
        }
        return parent::updateStatus($process, $status);
    }

}

这应该很容易地查明索引器何时失效以及导致该索引器的调用跟踪。


10

由于其他人已经回答了您的具体问题。我认为最好解释一下为什么需要索引以及索引如何与Magento以及与现代数据库的关系

索引:按字母顺序排列的名称,主题等列表,并引用其出现的位置,通常在书的末尾找到。

那么就数据库而言,索引到底是什么?

索引是一种数据结构,它对一个或多个字段上的许多记录进行排序,并加快了数据检索的速度。这是为了避免在搜索数据库时扫描表跨越的磁盘块。

Magento索引是什么?EAV(实体属性值)的副产品又称为数据库内的数据库。使用多个查找表,可以将标记为索引的所有属性收集在一起,以合并到所有查找表的一个平面表中,以实现更快的查询,更少的I / O和CPU周期。

我记得有人提到,最初开发Magento时,优先级列表上的灵活性很高,这是可以理解的,为什么他们选择使用EAV数据模型。然而,最终,这种灵活性的成本是以性能为代价的,并且从一开始就困扰着Magento。

通常,Magento工程师首先要负责构建尽可能灵活,可定制的系统,然后再担心性能。为什么Magento这么慢?

EAV非常适合数据仓库,但对交易而言则很糟糕。那么为什么我们需要索引呢?由于已经重新实现了关系模型的相同方法,因此Magento现在必须处理MySQL内部所做的所有事情。需要考虑的一些事情,例如MySQL表中已经存在的索引。考虑到这一点,现在考虑EAV数据模型:

  • Ë ntity =表
  • ttribute =字段
  • V ALUE =值

必须重新实现相同的功能,这是非常“反模式”的IMO。

此外,这同样的原因,你发现var/locks它的索引器使用锁定索引过程。同样的原因,数据库具有行/表锁定。

现在,当一条记录(例如一个产品值)已经更改时,必须更新flat tableindex(如MySQL所称的那样),以反映对新更改的数据的查询,以便快速有效地找到它们,而无需扫描大量记录。平面表的存在与MySQL具有它们的原因完全相同,而没有这样的索引(如书),它需要全表扫描来检索记录。这意味着磁盘和内存都有大量的I / O以及CPU周期来定位请求的数据,这对性能非常不利。

由于Magento使用EAV数据模型,因此必须扫描许多查找表才能将所有数据组合在一起以找到请求的数据。如果禁用Flat目录,则会发生这种情况。与MySQL一样,扫描记录还是使用索引(平面表)来快速查找记录,同时保留宝贵的I / O周期。创建表而不添加任何索引与不使用magento中的平面表相同。尽管这两种情况在不同的情况下都能很好地发挥作用,但请参阅Sonassi的Ben对这个问题的很好回答。(提示涉及了解数据范围。)

尽管这不是您问题的直接答案,但了解运动部件并为它们做好准备应该可以减轻索引带来的一些麻烦。“ 对待问题而不是症状。

对现代数据库系统的内部进行更多的探索可以帮助更好地了解索引的必要性和方式,以及索引如何与Magento的索引(某种程度上)相关。

总结:在盲目应用解决方案之前先了解您的问题范围。由于并非每一位数据都完全相同,因此在计划和实施解决方案之后,您会对问题有很好的/充分的了解。数据库优化对于变更管理可能是非常有益的。如防止恐惧DEADLOCKS

您可能还需要考虑将所有索引器Manual设置为,并设置其他过程以在非高峰时间(管理员不在时)重建索引。仅Product PricesStock Status应设置为Update on Save

现在,从技术角度考虑索引的工作方式。主模块负责索引Mage_Index。索引的基本模型:IndexerProcessEvent

Mage_Index_Model_Indexer如果是索引器,则与其他模块模块的所有交互都Mage_Index通过此服务进行。它包含以下方法:

  • processEntityAction() 创建并注册事件并开始建立索引过程
  • logEvent() 创建一个事件并将其注册以用于后续索引;
  • indexEvent() 运行索引事件;
  • getProcessesCollection()返回所有过程的集合,例如产品属性,产品价格,目录URL重写等。通常在更改本质后,例如方法_afterSave_afterCommit我们执行部分重新索引。

Mage_Index_Model_Process或过程是你的索引的精髓,存储状态,最后运行操作。所有进程都存储在表中index_process。该程序具有一个getIndexer()返回模型索引的方法。索引模型的过程委派了大多数任务。

Mage_Index_Model_Event存储有关发生的事件的信息。例如,我们存储产品,保存后创建一个新事件,并存储有关我们刚刚保存了哪种类型的实体的信息,即哪些ID具有精神以及我们对该物质执行了什么操作。

何时发生失效的一般列表:

  1. 目录/产品(保存,删除,MASS_ACTION)
  2. 目录/类别(保存,删除)
  3. 目录/ resource_eav_attribute(保存,删除)
  4. 客户/组(SAVE)
  5. 目录库存/库存项目(SAVE)
  6. 标签/标签(保存)
  7. 核心/存储(保存,删除)
  8. 核心/ store_group(保存,删除)
  9. 核心/网站(保存,删除)

config.xml保存事务后,模块中已注册索引的任何资源模型。 afterCommitCallback()被称为前缀。这是记录索引事件的位置,因为它是在成功事务结束时。

...并且令我感到遗憾的是,EAV仍在Magento 2中存在。

参考文献:


By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.