BAUSTELLE: Zusätzliche Indizes für die Datenbank

[vr]

Wir wissen u.U. nicht, wie die heissen Einige werden die Indexempfehlungen manuell angelegt haben, und wir haben bisher keine Namenskonvention für Indizes festgelegt, und selbst dann kann es Tippfehler beim Anlegen gegeben haben, fürs Funktionieren ist der Indexname Wurst.

Wir müssen dafür das Schema abfragen. Kriegen wir schon hin. Im update skript aber knifflig

Grüße, Volker

[speedy]

Gibt es denn keinen SQL-Befehl um alle Indizes einer Datenbank oder Tabelle auf einmal zu löschen ?
Konnte gerade nichts finden.

[vr]

Hallo speedy,

Nein. Das wird auf ein SQL-Skript hinauslaufen. Du veränderst ja in dem Fall nicht die Daten, sondern die Architektur der DB, dafür gibts keine einfachen SQL-Statements, die mal eben das halbe Dorf plattmachen, um Platz für ein Neubaugebiet zu schaffen Besser isses.

Grüße, Volker

[ds170477]

Also ich habe die drei Indexes ausgeführt. Sobald man sie wiederholt anlegen möchte,
kommt folgende Fehlermeldung (Mysqldumper):

MySQL meldet:
Duplicate key name 'orders_id'

Fehler bei der Anfrage:
alter table orders_products add index orders_id (orders_id), add index products_id (products_id);

Somit hat es sich doch mit doppelten Einträgen erl. oder?
BZW. man weiss welche vorher gelöscht werden müssten

Gruss

Daniel

[ds170477]

Hallo zusammen,

ich habe im einem anderen Forum, weitere Indexes gefunden. Ich habe Sie bereits angewendet, doch gibt es ein Problem, wenn man einen Artikel neu anlegen bzw. bearbeiten möchte. Vielleicht hilft es euch weiter, dass super schnelle modified eCommerce Shopsoftware Richtung Lichtgeschwindigkeit zu boosten.

Die Datei müsste aber wie gesagt bereinigt werden, da doppelte Indexes (sichtbar in PHP-Admin) entstehen. Ich hoffe mal, dass ich auch mal euch weiterhelfen konnte.

Gruss

Daniel

Code: SQL  [Auswählen]

ALTER TABLE address_book ADD INDEX ( entry_country_id );
ALTER TABLE address_book ADD INDEX ( entry_zone_id );

ALTER TABLE banners ADD INDEX ( STATUS , banners_group );

ALTER TABLE categories ADD INDEX ( categories_id , parent_id , categories_status , sort_order );
ALTER TABLE categories ADD INDEX ( parent_id , categories_status , sort_order );
ALTER TABLE categories ADD INDEX ( categories_status );

ALTER TABLE content_manager ADD INDEX ( languages_id , file_flag , content_status , sort_order );
ALTER TABLE content_manager ADD INDEX ( content_id , languages_id );
ALTER TABLE content_manager ADD INDEX ( content_group , languages_id );

ALTER TABLE manufacturers ADD INDEX ( manufacturers_id , manufacturers_name );

ALTER TABLE orders ADD INDEX ( customers_status );

ALTER TABLE products ADD INDEX ( products_id , products_status , products_date_added );
ALTER TABLE products ADD INDEX ( products_status , products_id , products_date_added );
ALTER TABLE products ADD INDEX ( products_status , products_id , products_price );
ALTER TABLE products ADD INDEX ( products_status , products_ordered , products_id );
ALTER TABLE products ADD INDEX ( products_status , products_model , products_id );
ALTER TABLE products ADD INDEX ( products_id , products_startpage , products_status , products_startpage_sort );
ALTER TABLE products ADD INDEX ( products_date_available , products_id );
ALTER TABLE products ADD INDEX ( products_quantity );
ALTER TABLE products ADD INDEX ( products_sort );
ALTER TABLE products ADD INDEX ( products_tax_class_id );
ALTER TABLE products ADD INDEX ( manufacturers_id );

ALTER TABLE products_attributes ADD INDEX ( products_id , options_id , options_values_id , sortorder );
ALTER TABLE products_attributes ADD INDEX ( options_values_id );
ALTER TABLE products_attributes ADD INDEX ( sortorder );
ALTER TABLE products_attributes ADD FULLTEXT (attributes_model );

ALTER TABLE products_description ADD INDEX ( language_id , products_keywords );
ALTER TABLE products_description ADD INDEX ( language_id , products_name );
ALTER TABLE products_description ADD FULLTEXT (products_name );
ALTER TABLE products_description ADD FULLTEXT (products_description );
ALTER TABLE products_description ADD FULLTEXT (products_short_description );

ALTER TABLE products_options_values ADD INDEX ( products_options_values_name , language_id );
ALTER TABLE products_options_values ADD FULLTEXT (products_options_values_name );
ALTER TABLE products_options_values_to_products_options ADD INDEX ( products_options_id );
ALTER TABLE products_options_values_to_products_options ADD INDEX ( products_options_values_id );

ALTER TABLE products_to_categories ADD INDEX ( categories_id , products_id );

ALTER TABLE personal_offers_by_customers_status_0 ADD INDEX ( products_id , quantity );
ALTER TABLE personal_offers_by_customers_status_1 ADD INDEX ( products_id , quantity );
ALTER TABLE personal_offers_by_customers_status_2 ADD INDEX ( products_id , quantity );
ALTER TABLE personal_offers_by_customers_status_3 ADD INDEX ( products_id , quantity );

ALTER TABLE sessions ADD INDEX ( sesskey , expiry );

ALTER TABLE shipping_status ADD INDEX ( language_id );

ALTER TABLE specials ADD INDEX ( products_id , STATUS , specials_date_added );
ALTER TABLE specials ADD INDEX ( STATUS , expires_date );

ALTER TABLE tax_rates ADD INDEX ( tax_zone_id );
ALTER TABLE tax_rates ADD INDEX ( tax_class_id , tax_priority );

ALTER TABLE whos_online ADD INDEX ( customer_id );
ALTER TABLE whos_online ADD INDEX ( session_id );
ALTER TABLE whos_online ADD INDEX ( time_last_click );

ALTER TABLE zones_to_geo_zones ADD INDEX ( zone_id );
ALTER TABLE zones_to_geo_zones ADD INDEX ( geo_zone_id );
ALTER TABLE zones_to_geo_zones ADD INDEX ( zone_country_id , zone_id );
 

Auszuführen im PHP Admin, oder in eine .txt Datei hineinkopieren und die Datei importieren...

Have fun

[gelbor1]

Irgendwie verliert man bei den ganzen vorschlägen den Überblick^^, eventuell sollten wir mal sortieren, welche queries zum welchen Zweck etc. ...

[speedy]

Kann das bitte einmal ein Profi auswerten und dann gleich die empfohlenen Einstellungen für modified eCommerce Shopsoftware in den Standard übernehmen.
Ich blick da auch nicht mehr durch und wildes rumprobieren ist eher nicht so vorteilhaft.

[hstreicher]

Hallo Alle,
ein Problem mit den ganzen Vorschlägen die hier veröffentlicht werden ist, dass es alles immer Schrotschüsse sind in der Hoffnung etwas zu treffen und dass Kollateralschäden billigend in Kauf genommen werden.

Soll heissen nicht jeder Index ist für jeden Shop gut, der eine hat wenig Produkte mit vielen Varianten (Typisch bei Bekleidung) der andere viele Produkte ohne Varianten.

Also ich versuch mich jetzt mal an einer einfachen Erklärung wo ein Index gut tut und wo man sich orientieren kann.

Zuerst mal was ein paar Worte zur Einführung wie funktioniert eine Datenbank.

-Profis bitte nicht totlachen-

Stellt euch eine Datenbank einfach vor wie einen Ordner und jeder Datensatz ist ein Blatt Papier, wenn ich einen Datensatz einfüge lege ich einfach das Blatt oben in den Order, (ist schön schnell)
Jetzt suche ich etwas, dazu muss ich -ohne Index- den Order von vorne bis hinten durchblättern und jedes Blatt ansehen d.h. im Durchschnitt muss ich den halben Ordner durchblättern bis ich den gewünschten Datensatz finde .

Ein Index ist ein Inhaltsverzeichnis, also im meinem Beispiel ein Deckblatt oben auf, auf dem steht an welcher Stelle ich den gewünschten Datensatz finde, so weit so schön, aber so einen Index zu verwalten macht Arbeit, da er jedes mal wenn ein Datensatz eingefügt, gelöscht oder verändert wird aktualisiert werden muss, für mein Blatt Papier heisst dass dass wenn ich den neuen Eintrag nicht zwischen zwei vorhandene quetschen kann, ich das ganze Blatt wegwerfen muss und neu schreiben, das kann die Datenbank stark belasten (entgegen meinem Beispiel ist übrigens das sortierte Einfügen von Daten ein Horror für einen Index, wer mehr wissen will sollte sich mit B-Tree oder Bayer Bäumen beschäftigen).

Wie entscheidet die Datenbank ob sie einen Index verwendet zuerst liest sie die Verwaltungsinformationen, sucht welche Indexe passen würden bzw verwendet werden können, dann prüft sie die Selektivität (Kardinalität) des Indexes und entscheidet (mit begrenzter Intelligenz) ob er verwendet wird oder nicht Beispiel die Kundennr im Kundenstamm ist einmalig (unique) und hat damit die bestmögliche Selektivität auf der anderen Seite ist z.B. das Land aus dem Kunden kommen das dürften meist wenige verschiedene sein und weisst deshalb eine geringe Selektivitaet aus.

Wer mehr wissen will kann sich von MySQL mit dem "explain" Befehl sagen lassen welche Indexe bei welcher Abfrage verwendet werden.

- jetzt die Hardwareseitigen Probleme -

MySQL speichert Daten und Indexe in separaten Dateien, d.h. jedes mal wenn ein Index verwendet wird muss eine extra Datei geöffnet werden. -das ist langsam-
Daten von der Platte lesen ist langsam, Daten im Hauptspeicher sind schnell verarbeitet .
Festplatten sind in Clustern organisiert, wenn also Daten von der Platte gelesen werden dann wird immer mindestens ein ganzer Cluster von der Platte in den Speicher geladen, egal ob Daten oder Index (üblicherweise 4 KB)

also DatenTabelle öffnen,
Index entscheiden
Index(e) öffnen
Index einlesen, auswerten
zurueck zu den Daten
Datensatz anfahren und einlesen
-viel Arbeit-

also wann lohnt der Index
phpMyAdmin liefert alle notwendigen Informationen zur Datenbank bei Speicherplatzverbrauch
einfach die Tabelle aufrufen und ansehen.

Beispiel Products: bei 73 Produkten sind das 9 KB, da bringt ein Index nix.

(er kann aber notwendig sein um Unique constraints zu verwalten)

Hier mal ein abschreckendes Beispiel:
Tabelle products_options_values_to_products_options
Zeilen 946

Speicherplatzverbrauch Typ Verbrauch
Daten 12,298 Bytes
Index 23,552 Bytes
Insgesamt 35,850 Bytes

Hier ist der Index doppelt so groß wie die Daten also ein echter Performance Killer

XT(C|M) bietet die Möglichkeit die Querys mit Laufzeit zu speichern, also bevor Ihr da wie verrückt Indexe erstellt die den Shop runter ziehen erst auswerten und um euch den Tag endgültig zu verderben, ein Index kann die eine Abfrage beschleunigen und die andere ausbremsen das kann man umgehen indem man die Abfrage umschreibt .

Einen Index kann man vermeiden indem man ihn in eine Berechnung einbezieht .

z.B. aus:

Code: SQL  [Auswählen]

SELECT * FROM tabelle WHERE feld=1
 

macht man:

Code: SQL  [Auswählen]

SELECT * FROM tabelle WHERE feld+0=1
 

dann wird der (Performance-)Killerindex nicht verwendet

so und jetzt rufen Staubsauger und Küche -
schönen Sonntag

[ds170477]

Hallo  hstreicher,

das nenne ich mal eine saubere Erklärung.

Danke

Gruss

Daniel

[Tomcraft]

Ich denke, wenn Volker wieder ein wenig mehr Zeit hat, dann wird er weiter an dem Thema arbeiten. EIn paar Indizes haben wir in modified eCommerce Shopsoftware 1.04 schon eingeführt.

Sicherlich werden nicht einfach alle übernommen, sondern genau geprüft, welche davon Sinn machen.

Grüße

Torsten

[Haina]

[...]
Sicherlich werden nicht einfach alle übernommen, sondern genau geprüft, welche davon Sinn [...]

Genau das ist es was die Qualität von modified eCommerce Shopsoftware bisher ausmacht, und ich bete, dass das so bleibt, ist wirklich enorm wichtig. Gibt schon genug Foren, die Masse vor Klasse stellen.

Liebe Grüße an das tolle Team hier

[Tomcraft]

Genau das ist es was die Qualität von modified eCommerce Shopsoftware bisher ausmacht, und ich bete, dass das so bleibt, ist wirklich enorm wichtig. Gibt schon genug Foren, die Masse vor Klasse stellen.
[...]

Na wieso sollte das denn nicht so bleiben?

Grüße

Torsten

[gelbor1]

Wir haben ja mittlerweile ein paar Datenbank-Experten an Board.
Hat sich hier schon was getan?

[DokuMan]

Ich werde mir das morgen nochmal ansehen und eine neue Liste zusammenstellen...

[Tomcraft]

Wolltest du mit dem "Tuning-Primer.sh" mal schauen oder wie willst du vorgehen?

Grüße

Torsten