SELECT-Anweisung nicht verwenden possible_keys

Ich habe eine Tabelle aus einem legacy-system, die nicht über einen Primärschlüssel verfügen. Es zeichnet Transaktions-Daten für die Ausstellung von Materialien in einer Fabrik.

Für simplicities Willen, sagen wir, jede Zeile enthält die Jobnummer, part_number, Menge & date_issued.

Fügte ich ein index auf das Datum ausgestellt Spalte. Wenn ich ein EXPLAIN SELECT * FROM issued_parts WO date_issued > '20100101', zeigt er das an:

+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+ 
| 1 | SIMPLE | issued_parts | ALL | date_issued_alloc | NULL | NULL | NULL | 9724620 | Mit denen | 
+----+-------------+----------------+------+-------------------+------+---------+------+---------+-------------+

So sieht es der Schlüssel ist, aber es nicht nutzen?
Kann mir jemand erklären, warum?

  • Benennen einer Spalte key nicht machen es zu einem. Aber ich bin nicht vollständig die Frage zu verstehen, ordnen Sie die key - Spalte als primary key, wenn Sie möchten, dass die Art von Funktionalität. Wenn nicht, sind Sie gehen zu müssen, um die Versorgung von mehr Informationen (wie die aktuelle schema-Instanz).
InformationsquelleAutor Paul Wieland | 2011-03-31
  1. 10

    Etwas sagt mir, dass der MySQL Query Optimizer richtig entschieden.

    Hier ist, wie können Sie sagen. Laufen diese:

    Anzahl der Zeilen

    SELECT COUNT(1) FROM issued_parts;

    Anzahl der Zeilen, die mit Ihrer Suchanfrage übereinstimmen

    SELECT COUNT(1) FROM issued_parts WHERE date_issued > '20100101';

    Wenn die Anzahl der Zeilen, die Sie tatsächlich abrufen von mehr als 5% der in der Tabelle Gesamtzahl der MySQL Query Optimizer entscheidet, es wäre weniger Aufwand zu tun, einem full table scan.

    Nun, wenn Sie Ihre Abfrage genauer, zum Beispiel mit dieser:

    SELECT * FROM issued_parts WHERE date_issued = '20100101';

    dann bekommen Sie einen anderen plan ERKLÄREN insgesamt.

    • Deine Antwort ist technisch korrekt, aber "der MySQL Query Optimizer richtig entschieden" ist es nicht. Ich bin mehr oder weniger in der gleichen situation, und in meinem Fall mit dem Schlüssel (zu erzwingen) macht die Abfrage sehr viel schneller.
    • Ich amgeting 1500 Datensätze 200k. Noch kein Schlüssel verwendet.
    • Mich auch... 15,080 aus 709,743
    • Versuchen Sie es mit force key, funktioniert es für Sie?
    InformationsquelleAutor RolandoMySQLDBA
  2. 0

    possible_keys Namen der Tasten mit den entsprechenden Spalten, aber das bedeutet nicht, dass jede Taste in es ist, nützlich zu sein für die Abfrage. In diesem Fall sind keine.

    InformationsquelleAutor Lightness Races with Monica
  3. 0

    Gibt es mehrere Arten von Indizes (Indizes?). Ein hash-index ist ein schneller Weg, um eine Suche auf ein Element zu einem bestimmten Wert. Wenn Sie eine Reihe von diskreten Werten, die Sie Abfragen gegen, (zum Beispiel eine Liste der 10 Termine), dann kannst du berechnen eines Hashwertes für jeden dieser Werte, und suchen Sie im index nach. Da Sie nicht tun, eine Suche auf einen bestimmten Wert, sondern eher einen Vergleich zu tun, ein hash-index wird Ihnen nicht helfen.

    Auf der anderen Seite, ein B-Tree-index kann Ihnen helfen, denn es gibt eine Reihenfolge der Elemente ist es die Indizierung. Zum Beispiel finden Sie hier: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html für mysql (Suche nach B-Tree-Index-Eigenschaften) . Möglicherweise möchten Sie überprüfen, dass Ihre Tabelle ist die Verwendung einer b-Baum-index es-index-Spalte.

    InformationsquelleAutor Zak
Schreibe einen Kommentar