MySQL - warum nicht jedes Feld indizieren?


107

Kürzlich habe ich das Wunder der Indizes gelernt und die Leistung hat sich dramatisch verbessert. Nach allem, was ich gelernt habe, kann ich die Antwort auf diese Frage nicht finden.

Indizes sind großartig, aber warum konnte nicht jemand alle Felder indizieren, um die Tabelle unglaublich schnell zu machen? Ich bin sicher, es gibt einen guten Grund, dies nicht zu tun, aber wie wäre es mit drei Feldern in einer Tabelle mit dreißig Feldern? 10 in einem 30er Feld? Wo soll man die Grenze ziehen und warum?


7
Versuchen Sie, einen Wert in eine Tabelle mit mehr als 10.000 indizierten Einträgen einzufügen. Alle Einträge müssen aufgrund von Einfügungen / Löschvorgängen aktualisiert werden. Dies ist ein enormer Zeitaufwand und ein gewisser Speicheraufwand, wenn jeder Wert einen Index hat
Jesus Ramos,

5
Neben der Speicherplatz- und Schreibleistung gibt es noch einen weiteren Grund: Die Verwendung mehrerer Indizes für einen einzelnen Tabellenzugriff ist sehr ineffizient . Das heißt, selbst wenn Sie einen Index für jede Spalte haben, ist die Auswahlleistung nicht sehr gut, wenn in der WHERE-Klausel auf mehrere Spalten zugegriffen wird. In diesem Fall ist ein mehrspaltiger Index am besten.
Markus Winand

1
Wenn Sie eine Tabelle mit 30 Feldern haben, sollten Sie sich Ihre Tabellenstrukturen genau ansehen. Es sollte sehr schwer sein, mit ihnen zu arbeiten.
Webs

Antworten:


122

Indizes belegen Speicherplatz (RAM); Zu viele oder zu große Indizes und die Datenbank müssen sie auf und von der Festplatte austauschen. Sie verlängern auch die Einfüge- und Löschzeit (jeder Index muss für jedes eingefügte / gelöschte / aktualisierte Datenelement aktualisiert werden).

Du hast kein unendliches Gedächtnis. Stellen Sie sicher, dass alle Indizes in den RAM passen = gut.

Du hast keine unendliche Zeit. Wenn Sie nur die Spalten indizieren, die Sie indizieren möchten, wird der Leistungseinbruch beim Einfügen / Löschen / Aktualisieren minimiert.


11
Schöne beiläufige Antwort, um allgemeines Verständnis zu vermitteln, aber nicht viel Hilfe bei der Bestimmung, wo die Grenze zwischen Indizes gezogen werden soll. Wie kannst du das wissen? Fügen Sie sie einfach zu allgemein WHERED-Feldern hinzu und hoffen Sie auf das Beste?
Andrew

@ Andrew anderthalb Jahre später, haben Sie die Antwort auf Ihre Frage gefunden?
Sinjai

1
@Sinjai Das Hinzufügen zu häufig verwendeten Spalten ist wahrscheinlich eine gute Faustregel. Aber sonst könnten Sie viel lesen, es stellt sich heraus, wenn Sie Experte für Indizes werden möchten. z.B. stackoverflow.com/questions/3049283/…
Andrew

Speicherplatz nicht vergessen.
jpmc26

27

Beachten Sie, dass jeder Index jedes Mal aktualisiert werden muss, wenn eine Zeile aktualisiert, eingefügt oder gelöscht wird. Je mehr Indizes Sie haben, desto langsamer ist die Leistung für Schreibvorgänge.

Außerdem belegt jeder Index weiteren Speicherplatz und Speicherplatz (wenn er aufgerufen wird), sodass möglicherweise auch Lesevorgänge verlangsamt werden (bei großen Tabellen). Überprüfen Sie dies heraus


6
Der Link ist für MS SQL Server . Diese Frage ist für MySQL
OMG Ponys

5
@OMG Die meisten Punkte im Link gelten für alle wichtigen RDBMS
RichardTheKiwi

5
@Richard aka cyberkiwi: Indizes werden von ANSI nicht abgedeckt - es ist ein Wunder, dass jeder Anbieter eine ähnliche Terminologie verwendet hat. Aber selbst dann verwenden nur SQL Server und MySQL die Terminologie "Clustered" und "Non-Clustered" - dies bedeutet in SQL Server mehr als in MySQL. Es gibt keine Garantie dafür, dass Empfehlungen für einen Anbieter auf einen anderen angewendet werden sollten.
OMG Ponys

3
@omg Die ersten 6 Punkte gelten für alle DBMS. Überspringen Sie die nicht / gruppierten, dann unten sind weitere Punkte bezüglich der allgemeinen Indizierung, auch auf Punkt. Wenn Sie bestimmte Dinge haben, auf die Sie hinweisen möchten, rufen Sie sie an. Ansonsten sieht es so aus, als würden Sie alle Antworten negieren, die aus den Kommentaren (einschließlich Ihrer gelöschten Antwort) hervorgehen, dass niemand Ihrer Einschätzung zustimmt.
RichardTheKiwi

10

Sie müssen die CRUD-Bedürfnisse ausgleichen. Das Schreiben in Tabellen wird langsam. Wo die Linie gezogen werden soll, hängt davon ab, wie auf die Daten zugegriffen wird (Sortierfilterung usw.).


und auch jeder Index nimmt etwas Datenbankspeicherplatz ein
Acanthus

@ Acanthus: Die kleinsten verfügbaren Festplatten werden in Gigabyte gemessen .
OMG Ponys

4
@OMG aber nicht RAM, wie Brian betont. Es ist niemals eine gute Idee, mehr zu speichern, als Sie benötigen. Daten- / Index-Caching im RAM, Sicherungsmedien (Versionen, die pro Band passen usw.) werden alle von nutzlosen Indizes beeinflusst
RichardTheKiwi

9
Die Fülle einer Ressource ist kein Grund für Verschwendung oder Ineffizienz.
Smandoli

6
Stimmt, aber die Einschränkungen sind nicht so, wie sie vor mehr als 10 Jahren waren.
OMG Ponys

2

Die Indizierung beansprucht mehr zugewiesenen Speicherplatz sowohl vom Laufwerk als auch vom RAM, verbessert aber auch die Leistung erheblich. Wenn das Speicherlimit erreicht ist, gibt das System den Speicherplatz leider frei und gefährdet die Leistung. In der Praxis sollten Sie kein Feld indizieren, von dem Sie glauben, dass es keinen Datenüberquerungsalgorithmus enthält, weder das Einfügen noch das Suchen (WHERE-Klausel). Aber du solltest wenn anders. Standardmäßig müssen Sie alle Felder indizieren. Die Felder, die Sie als nicht indizierend betrachten sollten, sind, wenn die Abfragen nur vom Moderator verwendet werden, es sei denn, sie benötigen ebenfalls Geschwindigkeit


2

Diese Antwort basiert auf meiner persönlichen Meinung. Ich benutze meine mathematische Logik, um zu antworten

Die zweite Frage betraf die Grenze, an der angehalten werden soll. Lassen Sie uns zunächst eine mathematische Berechnung durchführen. Nehmen wir an, wir haben N Zeilen mit L Feldern in einer Tabelle. Wenn wir alle Felder indizieren, erhalten wir L neue Indextabellen, in denen jede Tabelle in a sortiert wird Sinnvolle Weise die Daten des Indexfeldes, auf den ersten Blick, wenn Ihre Tabelle ein W-Gewicht hat, wird es W * 2 (1 Tera wird 2 Tera), wenn Sie 100 große Tabellen haben (ich habe bereits in einem Projekt gearbeitet, in dem die Tabellennummer war um 1800 Tisch) verschwenden Sie 100-mal diesen Platz (100 Tera), dies ist alles andere als weise.

Wenn wir Indizes in allen Tabellen anwenden, müssen wir über Indexaktualisierungen nachdenken, wenn ein Update alle Indexaktualisierungen auslöst. Dies ist eine Auswahl aller ungeordneten Äquivalente in der Zeit

Daraus schließe ich, dass Sie in diesem Szenario haben, dass, wenn Sie diese Zeit verlieren, es vorzuziehen ist, sie in einer Auswahl oder einem Update zu verlieren, denn wenn Sie ein Feld auswählen, das nicht indiziert ist, werden Sie nicht für alle Felder eine weitere Auswahl auslösen nicht indiziert

was zu indizieren?

Fremdschlüssel: ist ein Muss basierend auf

Primärschlüssel: Ich bin mir noch nicht sicher, ob jemand, der dies liest, in diesem Fall helfen könnte

andere Felder: Die erste natürliche Antwort ist die Hälfte der verbleibenden Felder. Warum: Wenn Sie mehr indizieren sollten, sind Sie nicht weit von der besten Antwort entfernt. Wenn Sie weniger indizieren sollten, sind Sie auch nicht weit, weil wir wissen, dass kein Index schlecht und alle indiziert sind ist auch schlecht.

Aus diesen 3 Punkten kann ich schließen, dass wenn wir L Felder haben, die aus K Schlüsseln bestehen, die Grenze ungefähr ((L-K)/2)+Kmehr oder weniger bei L / 10 liegen sollte

Diese Antwort basiert auf meiner Logik und meinen persönlichen Grundsätzen


1

Es ist keine gute Idee, alle Spalten in einer Tabelle zu indizieren. Dadurch wird das Lesen der Tabelle sehr schnell, das Schreiben wird jedoch auch viel langsamer. Wenn Sie in eine Tabelle schreiben, in der jede Spalte indiziert ist, müssen Sie den neuen Datensatz in diese Tabelle einfügen und dann die Informationen jeder Spalte in eine eigene Indextabelle einfügen.


Ich bin mir nicht sicher, ob es das Lesen der Tabelle blitzschnell machen würde, insbesondere wenn die Datentabelle nur 100 MB groß ist, die Indextabelle jedoch 300 MB oder mehr.
David

Alles, was Sie gesagt haben, wurde bereits gesagt.
Vael Victus
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.