Das ist komisch. Ich versuche, Ansichten in MySQL zu verwenden (ich bin relativ neu in MySQL mit mehr Erfahrung mit Sybase und SQL Server). Wie auch immer, dieses neue Projekt verwenden wir MySQL, da es eine gute Leistung zu haben scheint. Um jedoch die Suche nach einem Web-Frontend einfacher zu gestalten, haben wir uns entschieden, einige Ansichten zu erstellen, die alle gut funktionieren, deren Ausführung aber ewig dauert.
Die Ansichten sind sehr einfach, wählen Sie einfach Anweisungen (diese Tabellen enthalten einige Millionen Zeilen) . Sagen Sie zum Beispiel diese Abfrage:
%Vor%Wenn es als normal ausgeführt wird, dauert die Auswahl etwa 1,5 Sekunden, um ein Ergebnis zurückzugeben.
Wenn diese Abfrage jedoch in eine Ansicht eingefügt wird (d. h.
) %Vor%Die Abfrage dauert etwa 10 mal länger (22-30 Sekunden). Ich denke also, dass es eine Optimierung oder Query-Caching gibt, die nicht mit Views funktioniert, oder vielleicht gibt es einige Einstellungen, die wir in der MySQL-Konfiguration verpasst haben. Aber gibt es eine Möglichkeit, diese Ansicht zu beschleunigen, so ist es nur ein schöner Platzhalter für diese Abfrage?
Ausführen von EXPLAIN für die zwei Abfragen: Die normale Auswahl ergibt:
1, EINFACH, classifier_results, ALL, idx_date,,,, 594845, Verwendung wo; Verwenden von temporär; Verwenden von filesort
Die Auswahl der Ansicht ergibt:
1, PRIMÄR,, ALL,,,,, 100, 2, DERIVED, classifier_results, ALL, idx_date,,,, 594845, Verwenden wo; Verwenden von temporär; Verwenden von filesort
Das ist ein wirklich häufiges Problem. Es kann sehr schwierig sein, DRY, wiederverwendbares SQL zu schreiben. Es gibt jedoch einen Workaround, den ich gefunden habe.
Wie bereits erwähnt, können und sollten Sie VIEWs dazu verwenden, wo immer dies möglich ist, indem Sie ALGORITHM = MERGE verwenden, damit alle Abfragen, die sie verwenden, in der where-Klausel der fusionierten SQL-Anweisung optimiert werden, anstatt die VIEW ausgewertet zu bekommen für die gesamte Sicht, die katastrophal groß sein kann.
In diesem Fall können Sie versuchen, eine gespeicherte Prozedur zu verwenden, die eine temporäre Sitzungstabelle als Workaround erstellt, da Sie MERGE aufgrund des Aspekts "group / count" nicht verwenden können.
Mit dieser Technik können Sie wiederverwendbare Abfragen schreiben, auf die von Middleware- / Framework-Code aus zugegriffen werden kann und die von anderen gespeicherten Prozeduren aufgerufen werden, so dass der Code enthalten, wartbar und wiederverwendbar bleibt.
i.e. Wenn Sie im Voraus wissen, dass die Abfrage unter bestimmten Bedingungen gefiltert wird, legen Sie diese in einer gespeicherten Prozedur ab. (Es kann effizienter sein, den Datensatz nachzufiltern, oder eine Kombination - es hängt davon ab, wie Sie die Daten verwenden und welche gemeinsamen Mengen benötigt werden).
%Vor%Wenn Sie jetzt mit diesen Daten arbeiten müssen, rufen Sie die Prozedur auf und wählen dann entweder das Ergebnis (möglicherweise mit zusätzlichen where-Klauselparametern) aus oder verknüpfen Sie es mit einer anderen Abfrage.
Die Tabelle ist eine temporäre Sitzungstabelle, so dass sie auch nach dem Aufruf der Prozedur erhalten bleibt. Der aufrufende Code kann ihn entweder löschen, sobald er mit den Daten fertig ist, oder er wird automatisch gehen, wenn die Sitzung abläuft oder ein nachfolgender Aufruf an den Sproc erfolgt.
Ich hoffe, das ist hilfreich.
MERGE kann hier wegen der count () - Aggregate in der Auswahlliste nicht verwendet werden; In diesen Fällen kann es hilfreich sein, TEMPTABLE anzugeben, damit die Engine nicht zwischen ihnen entscheiden muss. Sobald ich entschieden habe, welchen Algorithmus ich verwenden soll, würde ich mir den EXPLAIN-Plan ansehen und versuchen, einen Indexhinweis hinzuzufügen oder einen fehlenden Index zu finden.
Tags und Links sql view mysql query-optimization