BAUSTELLE: Zusätzliche Indizes für die Datenbank

[noRiddle (revilonetz)]

Jau, 'disabled' würde in 'Comment' stehen wenn man 'SHOW INDEX FROM XXX" laufen lässt.
phpMyAdmin zeigt das aber an wenn man auf "Struktur" klickt und dann unten auf "Indizes".
Ich hatte das schonmal bei einem Kunden der mySQLdumper benutzt hat um Daten drüberzubügeln.
Wenn der Import aus irgendeinem Grund abkackt sind einige Keys disabled weil die generierte Datei für jede Tabelle ein DISABLE KEYS setzt vor dem Import, anschließend zwar ein ENABLE KEYS, nur wenn der Import aus irgendeinem Grund abgebrochen wurde...

Genauso wichtig ist jedoch die Cardinality. Wenn die null ist oder nicht vergeben, dann wird der Index nicht benutzt, was kontraproduktiv ist.
Da hilft, wie bereits gesagt ein ANALYZE TABLE, danach sind die Cardinalities vergeben.
Je höher eine Cardinality ist desto eher wird der Index bei einem SELECT auch benutzt.
Bei PRIMARY KEYS und UNIQUE KEYS ist das eigtl. immer der Fall und die Cardinality ist dann gleich der Anzahl an Einträgen in der entprechenden Tabelle.

Gruß,
noRiddle

[Bonsai]

OK, dann muss ich mal .... wenn ich die Zeit finde ... mein Script anpassen um deaktivierte indicies zu erkennen und zu aktivieren.

Analyze table macht es ja schon.

[ShopNix]

Wenn Du schon dabei bist, kannst Du auch mal schaun, wie Du mit kombinierten Indizes umgehst.

So wie ich den Code interpretiere, werden die nicht bearbeitet.

Ich weiß nicht, ob das Ziel, Indizes automatisiert zu erzeugen, so sehr sinnvoll ist. Solche Tools gaukeln Sicherheit vor, wo keine ist. Tatsächlich wird das Script in Einzelfällen Vorteile haben, in anderen Fällen nicht, und in einigen Fällen sogar Nachteile mit sich bringen.

Betrachte ich nebenbei noch die Releasefähigkeit, werden die Nachteile wohl überwiegen.

Auch beim Backup stören überflüssige Indizes, auch wenn sie in den meisten Fällen im laufenden Betrieb nicht auffallen.

[webald]

Auch beim Backup stören überflüssige Indizes

Kannst Du das mal genauer begründen? Beim Backup sehe ich da kein Problem, wohl aber beim Restore.

[Bonsai]

Das Script ist eine Vorlage ..... damit Leute die wenig Kenntnisse haben, oder wie ich zu faul sind mich zwei Stunden duch myphpadmin zu klicken daraus ein EIGENES Script bauen können. Da das eine EINMAL-Aktion ist, sehe ich hier kein Release ....

[ShopNix]

@webald: gemeint ist die Sicherung des Dateisystems, nicht die per Dump.

@Bonsai: gemeint ist nicht die Releasefähigkeit Deines Scripts, sondern die des Shops.

Leute, die wenig Kenntnisse haben, sollten tunlichst die Finger von Modifikationen im Allgemeinen und der Datenbank im Besonderen lassen. Es ergibt nur in Ausnahmefällen Sinn, zusätzliche Indizes anzulegen, und da sollte man wissen, was man tut und warum man es tut.

[ShopNix]

Die Tabelle products_tags hat (zumindest bis Version v2.0.3.0 rev 10907) keinen Primärschlüssel. Infolgedessen gelang es einem Kunden, doppelte Datensätze zu produzieren. Auf welchem Wege entzieht sich meiner Kenntnis, immerhin hatte ich 4000 statt 250 Datensätze in der Tabelle. Ging ein wenig auf die Performance.

Hier die Lösung:

Code: SQL  [Auswählen]

CREATE TABLE tmp_products_tags SELECT * FROM products_tags;
TRUNCATE products_tags;
TABLE products_tags DROP KEY idx_products_options_values;
ALTER TABLE products_tags ADD UNIQUE KEY idx_products_options_values (`products_id`,`options_id`,`values_id`);
INSERT IGNORE INTO products_tags SELECT * FROM tmp_products_tags;
DROP TABLE tmp_products_tags;
 

Das scheint zu funktionieren.

[GTB]

Das ist in der kommenden Version bereits gemacht in r11814

Gruss Gerhard