Magentos indexering liknar bara indexering på databasnivå i andan. Som Anton säger är det en denormaliseringsprocess för att möjliggöra snabbare drift av en plats. Låt mig försöka förklara några av tankarna bakom Magento-databasstrukturen och varför den gör indexering nödvändig för att fungera med hastighet.
I en mer "typisk" MySQL-databas skulle en tabell för lagring av katalogprodukter vara strukturerad ungefär så här:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
Det här går snabbt att hämta, men det lämnar ett grundläggande problem för en e-handelsprogramvara:vad gör du när du vill lägga till fler attribut? Vad händer om du säljer leksaker och i stället för en storlekskolumn behöver du age_range
? Tja, du kan lägga till ytterligare en kolumn, men det bör vara klart att i en stor butik (tänk till exempel Walmart) skulle detta resultera i rader som är 90 % tomma och att försöka underhålla nya attribut är nästan omöjligt.
För att bekämpa detta problem delar Magento upp tabeller i mindre enheter. Jag vill inte återskapa hela EAV-systemet i det här svaret, så acceptera den här förenklade modellen:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Nu är det möjligt att lägga till attribut när du vill genom att ange nya värden i product_attributes
och sedan lägga in angränsande poster i product_attribute_values
. Detta är i princip vad Magento gör (med lite mer respekt för datatyper än vad jag har visat här). Nu finns det faktiskt ingen anledning för två produkter att ha identiska fält alls, så vi kan skapa hela produkttyper med olika uppsättningar av attribut!
Denna flexibilitet kostar dock. Om jag vill hitta color
av en tröja i mitt system (ett trivialt exempel), måste jag hitta:
product_id
av artikeln (i produkttabellen)attribute_id
förcolor
(i attributtabellen)- Slutligen det faktiska
value
(i tabellen attributvärden)
Magento brukade fungera så här, men det gick väldigt långsamt. Så för att tillåta bättre prestanda gjorde de en kompromiss:när butiksägaren har definierat de attribut de vill ha, fortsätt och generera det stora bordet från början. När något förändras, kärnvapen det från rymden och generera det igen. På så sätt lagras data i första hand i vårt trevliga flexibla format, men efterfrågas från en enda tabell.
Dessa resulterande uppslagstabeller är Magento "index". När du återindexerar spränger du den gamla tabellen och genererar den igen.
Hoppas det förtydligar saken lite!
Tack, Joe