Magento索引數據庫表名重新索引？

Question

哪些表格與的重新索引的索引的過程連接在magento中。 請分享相同的任何文件。因爲它是從原始帖子在採取

Answer 1

不能採取信貸這樣的：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 ... 

這是快速檢索，但它留下一個根本性的問題換了一塊電子商務的軟件：當你想添加更多屬性時你會做什麼？如果你賣玩具，而不是大小欄，你需要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所做的（對數據類型的尊重比我在這裏展示的要多一點）。事實上，現在沒有理由讓兩種產品具有完全相同的字段，因此我們可以使用不同的屬性集創建完整的產品類型！

但是，這種靈活性需要付出代價。如果我想找到我的系統（一個簡單的例子），襯衫的顏色，我需要找到：

• 項目的PRODUCT_ID（產品表）
• 顏色的attribute_id（以屬性表）
• 最後，實際值（在ATTRIBUTE_VALUES表）

Magento的使用這樣的工作，但它是死的慢。所以，爲了更好的表現，他們做出了妥協：一旦店主確定了他們想要的屬性，就從頭開始生成大表。當一些東西發生變化時，將它從空間中取出並重新生成。這樣，數據主要以我們良好的靈活格式存儲，但是從單個表中查詢。

這些生成的查找表是Magento的「索引」。當您重新編制索引時，您將炸燬舊桌子並重新生成。