Ist es in Ordnung, wenn ich 8 Indizes in einer Tabelle mit 13 Spalten erstelle?
Wenn ich Daten daraus wähle und die Ergebnisse nach einem Schlüssel sortiere, ist die Abfrage sehr schnell, aber wenn das Sortierfeld kein Schlüssel ist, ist es viel langsamer. Wie 40 mal langsamer.
Was ich im Grunde frage ist, ob es irgendwelche Nebenwirkungen gibt, viele Schlüssel in der Datenbank zu haben ...
Das Erstellen von Indizes für eine Tabelle verlangsamt alle Schreibvorgänge ein wenig, beschleunigt jedoch die Leseoperationen für die relevanten Spalten viel . Wenn Ihre Anwendung nicht viele Schreibvorgänge für diese Tabelle ausführt (was für die meisten Anwendungen zutrifft), wird es Ihnen gut gehen.
Erstellen Sie keine Indizes, die redundant oder unbenutzt sind. Erstellen Sie jedoch Indizes, die Sie zur Optimierung der von Ihnen ausgeführten Abfragen benötigen.
Sie wählen basierend auf Ihren Abfragen Indizes in einer beliebigen Tabelle aus. Jede Abfrage verwendet möglicherweise einen anderen Index. Daher lohnt es sich, Ihre Abfragen sorgfältig zu analysieren. Siehe meine Präsentation MENTOR Your Indexes . Ich beziehe mich auch auf ähnliche Informationen im Kapitel über die Indizierung in meinem Buch SQL Antipatterns: Vermeidung der Fallstricke der Datenbankprogrammierung .
Es gibt keine spezielle Regel darüber, wie viele Indizes zu viele sind. In Oracle SQL Tuning Pocket-Referenz , Autor Mark Gurry sagt:
Ich empfehle, Regeln zu vermeiden, die besagen, dass eine Website nicht mehr als eine bestimmte Anzahl von Indizes hat. Die Quintessenz ist, dass alle SQL-Anweisungen akzeptabel ausgeführt werden müssen. Es gibt IMMER einen Weg, dies zu erreichen. Wenn für eine Tabelle 10 Indizes erforderlich sind, sollten Sie 10 Indizes in die Tabelle einfügen.
Es gibt ein paar gute Tools, die Ihnen helfen, redundante oder ungenutzte Indizes für MySQL im Percona Toolkit zu finden : Ссылка und p-index-usage .
Kurz gesagt, jeder neue Index benötigt Platz (besonders wenn Sie InnoDB verwenden - siehe Abschnitt "Nachteile des Clusterns" in dieser Artikel ) und verlangsamt INSERTs, UPDATEs und DELETEs.
Nur Sie sind in der Lage zu entscheiden, ob Sie eine Beschleunigung in SELECT bekommen und die Häufigkeit, mit der es verwendet wird, ist es wert. Aber was auch immer Sie letztendlich entscheiden, stellen Sie sicher, dass Sie Ihre Entscheidung auf Messung basieren, nicht Raten!
P.S. INSERTs, UPDATEs und DELETEs mit WHERE können auch durch Index (e) beschleunigt werden, aber das ist ein anderes Thema ...
Die Kosten eines Indexes im Plattenspeicherplatz sind im Allgemeinen trivial. Die Kosten zusätzlicher Schreibvorgänge, um den Index zu aktualisieren, wenn sich die Tabelle ändert, sind oft moderat. Die Kosten für zusätzliche Sperren können sehr hoch sein.
Es hängt vom Lese-Schreib-Verhältnis in der Tabelle ab und davon, wie oft der Index tatsächlich verwendet wird, um eine Abfrage zu beschleunigen.
Indizes belegen Speicherplatz auf der Festplatte und benötigen Zeit zum Erstellen und Verwalten. Ungenutzte geben keinen Vorteil. Wenn es viele Kandidatenindizes für eine Abfrage gibt, kann die Abfrage verlangsamt werden, indem der Server den "falschen" für die Abfrage auswählt.
Verwenden Sie diese Faktoren, um zu entscheiden, ob Sie einen Index benötigen.
Es ist normalerweise möglich, Indizes zu erstellen, die NIE verwendet werden - zum Beispiel und ein Index auf ein (nicht Null) Feld mit nur zwei möglichen Werten, wird mit ziemlicher Sicherheit nutzlos sein.
Sie müssen die Abfragen Ihrer eigenen Anwendung erklären, um sicherzustellen, dass die häufig ausgeführten Abfragen nach Möglichkeit sinnvolle Indizes verwenden, und keine weiteren Indizes erstellen, als dafür erforderlich sind.
Sie können mehr erhalten, wenn Sie diesen Links folgen: Für mysql: Ссылка
Für DB2: Ссылка
Nehmen wir MySQL vom Tag an, obwohl OP es nicht erwähnt.
Sie sollten Ihre Frage bearbeiten und die Tatsache hinzufügen, dass Sie auch order by -Operationen ausführen (von einem Kommentar, den Sie zu einer Lösung gepostet haben). order by operations verlangsamt auch Abfragen (wie auch andere mysql-Ops), weil MySQL eine temporäre Tabelle erstellen muss, um die geordnete Ergebnismenge zu erreichen (mehr Info hier ). Wenn das Dataset es erlaubt, ziehe ich oft die Daten, die ich brauche, und ordne sie dann auf der Anwendungsebene an, um diesen Nachteil zu vermeiden.
Am besten ist es, Ihre am häufigsten verwendeten Abfragen zu ermitteln und Ihr Protokoll für langsame Abfragen zu überprüfen.