Ich habe eine Tabelle aus einem Legacy-System, die keinen Primärschlüssel hat. Es zeichnet Transaktionsdaten für die Ausgabe von Materialien in einer Fabrik auf.
Der Einfachheit halber sagen wir, jede Zeile enthält job_number, part_number, quantity & amp; date_issued.
Ich habe einen Index zu der Datumsspalte hinzugefügt. Wenn ich EXPLAIN SELECT * FROM ausstelle_teile WHERE date_issued & gt; '20100101', es zeigt dies:
%Vor%So sieht es den Schlüssel, aber benutzt es nicht? Kann jemand erklären warum?
Etwas sagt mir, dass das MySQL Query Optimizer korrekt entschieden hat.
Hier können Sie sagen. Führen Sie diese aus:
Anzahl der Zeilen
%Vor%Anzahl der Zeilen, die Ihrer Suchanfrage entsprechen
%Vor%Wenn die Anzahl der Zeilen, die Sie tatsächlich abrufen, 5% der Gesamtanzahl der Tabelle überschreitet, entscheidet das MySQL Query Optimizer, dass weniger Aufwand für einen vollständigen Tabellenscan erforderlich ist.
Wenn Ihre Abfrage nun genauer war, zum Beispiel:
%Vor%Dann erhalten Sie einen anderen EXPLAIN-Plan.
possible_keys benennt Schlüssel mit den relevanten Spalten, aber das bedeutet nicht, dass jeder Schlüssel für die Abfrage nützlich ist. In diesem Fall sind keine.
Es gibt mehrere Arten von Indizes (Indizes?). Ein Hash-Index ist eine schnelle Möglichkeit, nach einem Element mit einem bestimmten Wert zu suchen. Wenn Sie eine Reihe diskreter Werte haben, gegen die Sie abfragen (z. B. eine Liste von 10 Daten), können Sie für jeden dieser Werte einen Hash berechnen und im Index nachschlagen. Da Sie nicht nach einem bestimmten Wert suchen, sondern einen Vergleich durchführen, hilft Ihnen ein Hash-Index nicht.
Andererseits kann ein B-Tree-Index Ihnen helfen, weil er den Elementen, die er indexiert, eine Reihenfolge gibt. Siehe zum Beispiel: Ссылка für mysql (Suche nach B-Tree Index Eigenschaften) . Sie sollten überprüfen, ob Ihre Tabelle einen B-Tree-Index für die Indexspalte verwendet.