Ich verwende diese Abfrage, um alle Mitarbeiter von {Clients mit Namen beginnend mit Kleinbuchstaben "a"}:
zu erhalten %Vor% Die Spalte employees.client_id ist ein int mit INDEX client_id (index_id) . Die Unterabfrage sollte IMHO eine Liste von ID-s zurückgeben, die dann in der WHERE-Klausel verwendet wird.
Wenn ich die Abfrage% EXPLAIN verwendet, verwendet die primäre Abfrage keine Indizes ( type:ALL ). Aber wenn ich EXPLAIN
eine Liste aus der Unterabfrage (z. B. SELECT ... WHERE client_id IN (121,184,501) ), die EXPLAIN wechselt zu type:range und diese Abfrage wird um 50% schneller.
Wie kann ich sicherstellen, dass die Abfrage den Index für die von der Unterabfrage zurückgegebenen Daten verwendet - oder gibt es eine effizientere Methode zum Abrufen dieser Daten? (Das Abrufen der ID-Liste zum Anwendungsserver, das Verbinden und Senden einer zweiten Abfrage ist hier noch teurer).
Vielen Dank im Voraus.
Sollte schneller sein, da der Optimierer den effizientesten Plan auswählen kann. Wenn Sie es mit einer Unterabfrage schreiben, zwingen Sie es dazu, die Schritte in einer bestimmten Reihenfolge auszuführen, anstatt es die optimale Join-Reihenfolge wählen zu lassen.
Als allgemeine Regel sollten Unterabfragen vermieden werden, da sie in der Regel weniger leistungsfähig sind als eine Join-Abfrage (obwohl sie unter bestimmten Umständen unvermeidlich sind).
Für eine spezifische Erklärung warum
%Vor%ist langsamer als
%Vor%Sehen Sie sich diesen Teil des MySQL-Handbuchs an, besonders den dritten Punkt: Ссылка . Auch dieser Fehlerbericht .
Es lohnt sich, darauf hinzuweisen, dass Joins, die besser als Unterabfragen funktionieren, nicht für jedes vorhandene DBMS gelten. Das tut es allerdings für MySQL.
Sie können die Abfrage mit EXISTS neu schreiben. In MySQL gibt es definitiv eine Leistungsverbesserung. Weitere Hilfe zur Optimierung finden Sie unter: MySQL-In-Query-Optimierung