MySql - Self-Join - Full Table Scan (Kann nicht Index Scan)

Question

Ich habe folgende Self-Join-Abfrage:

SELECT A.id 
FROM mytbl  AS A 
LEFT JOIN mytbl AS B 
ON (A.lft BETWEEN B.lft AND B.rgt) 

Die Abfrage ist ziemlich langsam, und nach bei dem Ausführungsplan der Suche erscheint die Ursache zu sein eine vollständige Tabelle Scan in der JOIN. Die Tabelle hat nur 500 Zeilen, und da ich vermute, dass dies das Problem ist, habe ich sie auf 100.000 Zeilen erhöht, um zu sehen, ob sie die Auswahl des Optimierers beeinflusst hat. Es tat nicht, mit 100k Zeilen war es immer noch eine vollständige Tabelle scannen.

Mein nächster Schritt war, um zu versuchen und Kraft-Indizes mit der folgenden Abfrage, aber die gleiche Situation ergibt sich, einen vollständigen Tabellenscan:

SELECT A.id 
FROM categories_nested_set  AS A 
LEFT JOIN categories_nested_set AS B 
FORCE INDEX (idx_lft, idx_rgt) 
ON (A.lft BETWEEN B.lft AND B.rgt) 

Alle Spalten (id, LFT, RGT) sind Ganzzahlen, alle sind indiziert.

Warum macht MySql hier einen vollständigen Tabellenscan?

Wie kann ich meine Abfrage ändern, um Indizes anstelle eines vollständigen Tabellenscan zu verwenden?

CREATE TABLE mytbl (lft int(11) NOT NULL DEFAULT '0', 
rgt int(11) DEFAULT NULL, 
id int(11) DEFAULT NULL, 
category varchar(128) DEFAULT NULL, 
    PRIMARY KEY (lft), 
    UNIQUE KEY id (id), 
    UNIQUE KEY rgt (rgt), 
    KEY idx_lft (lft), 
    KEY idx_rgt (rgt)) ENGINE=InnoDB DEFAULT CHARSET=utf8 

Dank

Answer 1

Die folgende SO ist Frage der Lösung kritisch, da es auf der Kombination von Adjazenzlisten und Indizes sehr wenig Informationen:

MySQL & nested set: slow JOIN (not using index)

Es scheint eine grundlegende Vergleichsbedingung, dass das Hinzufügen löst die Verwendung von ein Index, wie folgt:

SELECT A.id 
FROM mytbl  AS A 
LEFT JOIN mytbl AS B ON (A.lft BETWEEN B.lft AND B.rgt) 
-- THE FOLLOWING DUMMY CONDITIONS TRIGGER INDEX 
WHERE A.lft > 0 
AND B.lft > 0 
AND B.rgt > 0 

Und keine Tabellenscans mehr.

EDIT: Vergleich der EXPLAIN-Funktion zwischen festen und nicht fixierte Version der Abfrage:

Answer 2

Sie haben viel von Indizes, von denen einige redundant sind. Lasst uns damit beginnen, einige von ihnen aufzuklären. Zu viele Indizes verlangsamen Einfügungen und Aktualisierungen.

PRIMARY KEY (lft), 
KEY idx_lft (lft), 

Da Sie bereits einen Primärschlüssel auf LFT definiert haben, ist es nicht erforderlich, was so überhaupt für einen anderen Index auf LFT. In ähnlicher Weise ist bei einem eindeutigen Index für rgt der zweite Index nicht erforderlich, der nachstehend aufgeführt ist.

UNIQUE KEY rgt (rgt), 
KEY idx_rgt (rgt) 

Schauen wir uns jetzt Ihre Anfrage an.

SELECT A.id 
FROM mytbl  AS A 
LEFT JOIN mytbl AS B 
ON (A.lft BETWEEN B.lft AND B.rgt) 

Dies ist sehr unwahrscheinlich, eine Abfrage, die in freier Wildbahn auftreten wird. Mit 500 Zeilen kann diese Abfrage sogar 5000 Zeilen erzeugen? Brauchen Sie wirklich den gesamten Schlüssel, der auf einmal erstellt wird? Der Grund, warum diese Abfrage langsam ist, liegt daran, dass mysql nur optimize range comparisions für Konstanten verwenden kann. Es ist wahrscheinlicher, dass Ihr tatsächlich Abfrage etwas wie folgt aussehen:

SELECT B.* 
FROM mytbl  AS A 
LEFT JOIN mytbl AS B 
ON (A.lft BETWEEN B.lft AND B.rgt) 
WHERE a.id = N; 

Wo Sie den Knoten für eine bestimmte ID erstellen. Dies wird Indizes verwenden und wird sehr schnell sein. Was ist der Sinn der Optimierung für eine Abfrage, die Sie nicht viel verwenden werden, wenn überhaupt?