2016-07-22 15 views
0

Ich habe eine Abfrage verantwortlich für die Ausgabe von Clients Liste, die regelmäßig von Benutzern ausgeführt wird.Warum MySQL-Abfrage von mysql-slow-log erscheint nicht langsam zu sein, wenn in PHPMyAdmin ausgeführt?

Die Abfrage ist:

SELECT SQL_CALC_FOUND_ROWS p.lname, p.fname, p.patronymic, p.job, 
     p.post, p.zip, p.city, p.address, p.id, p.additional, 
     p.people_type_id, p.gender, p.permissions, p.user_id, 
     p.user_id, p.grading, p.progress, p.full_name, p.b1a, 
     p.b1b, p.b1c, p.b2a, p.b2b, p.b2c, p.b3a, p.b3b, p.b3c, 
     p.b4a, p.b4b, p.b4c, p.b5a, p.b5b, p.b5c, p.b6a, p.b6b, 
     p.b6c, p.b7a, p.b7b, p.b7c, p.b8a, p.b8b, p.b8c, p.b9a, 
     p.b9b, p.b9c, p.b10a, p.b10b, p.b10c, p.b11a, p.b11b, 
     p.b11c, p.b12a, p.b12b, p.b12c, p.b13a, p.b13b, p.b13c, 
     p.b14a, p.b14b, p.b14c, p.b15a, p.b15b, p.b15c, p.b16a, 
     p.b16b, p.b16c, p.b17a, p.b17b, p.count, p.finish_count, 
     p.partyId, t.description, a.description, p.contact_through, 
     DATE_FORMAT(p.next_call, '%d-%m-%Y') as next_call, p.recruiter, 
     p.b17c, p.l1a, p.l1b, p.l1c, p.l2a, p.l2b, p.l2c, p.l3a, 
     p.l3b, p.l3c, p.l4a, p.l4b, p.l4c, p.l5a, p.l5b, p.l5c, 
     p.l6a, p.l6b, p.l6c, p.l7a, p.l7b, p.l7c, p.l8a, p.l8b, 
     p.l8c, p.l9a, p.l9b, p.l9c, p.l10a, p.l10b, p.l10c, p.l11a, 
     p.l11b, p.l11c, p.l12a, p.l12b, p.l12c, p.l13a, p.l13b, 
     p.l13c, p.l14a, p.l14b, p.l14c, p.c1a, p.c1b, p.c1c, p.c2a, 
     p.c2b, p.c2c, p.c3a, p.c3b, p.c3c, p.c4a, p.c4b, p.c4c, 
     p.c5a, p.c5b, p.c5c, p.c6a, p.c6b, p.c6c, p.c7a, p.c7b, 
     p.c7c, p.c8a, p.c8b, p.c8c, p.c9a, p.c9b, p.c9c, p.c10a, 
     p.c10b, p.c10c, p.c11a, p.c11b, p.c11c, p.c12a, p.c12b, 
     p.c12c, p.c13a, p.c13b, p.c13c, p.c14a, p.c14b, p.c14c, 
     p.c15a, p.c15b, p.c15c, p.c16a, p.c16b, p.c16c, p.c17a, 
     p.c17b, p.c17c, p.c18a, p.c18b, p.c18c, p.c19a, p.c19b, 
     p.c19c, p.c20a, p.c20b, p.c20c, p.c21a, p.c21b, p.c21c 
    FROM people p 
    JOIN people_progress_id a ON p.progress = a.proc_level_id 
    JOIN people_grading_id t ON p.grading = t.grading_level_id 
    WHERE p.category=3 
     and p.status = 1 
    ORDER BY p.city desc 
    LIMIT 0, 50; 

Es regelmäßig zu mysql-slow-Abfrageprotokoll ähnlich diese protokolliert wird:

# Time: 160718 17:18:32 
# [email protected]: server[server] @ localhost [] 
# Query_time: 4.098162 Lock_time: 0.000255 Rows_sent: 50 Rows_examined: 1508127 
SET timestamp=1468851512; 
SELECT SQL_CALC_FOUND_ROWS p.lname... 

Aber wenn ich dies in PHPMyAdmin laufen die Ausführungszeit ist kleiner als eine Sekunde. Gibt es einen Grund, warum das passiert? Und wie kann ich das beschleunigen?

+1

Da die Abfrage wird zwischengespeichert. Wenn Sie Ergebnisse aus dem Cache bekommen, dann ist da nicht viel Arbeit und es wird ziemlich schnell "ausgeführt". Dieser Effekt, den Sie feststellen, hängt nicht mit PHPMyAdmin zusammen, sondern nur, dass Sie eine Abfrage ausgeführt haben * und dann PHPMyAdmin verwendet haben, um dieselbe Abfrage auszuführen. Aber das zweite Mal wird es ausgeführt - das Ergebnis wird aus dem Cache gezogen, also haben Sie festgestellt, dass es schnell ist, wenn Sie es über PHPMyAdmin ausführen. Falsche Positive sind ein b *** h. – Mjh

+1

Diese Abfrage scheint einen vollständigen Tabellenscan durchzuführen. Was passiert, wenn einige der Zeilen zeitweise gesperrt sind? Was passiert, wenn viele Zeilen gesperrt sind? Aus diesem Grund scheint diese Abfrage manchmal schnell zu laufen, zu anderen Zeiten jedoch nicht. – e4c5

+0

Wenn Sie 'SELECT SQL_NO_CACHE .... (Rest Ihrer Abfrage)' ausführen, können Sie überprüfen, ob es sich um den Cache handelt, der die Abfragegeschwindigkeit beeinflusst. Wenn Sie * noch * schnelle Ergebnisse erzielen, ist @ e4c5 korrekt. Beide Szenarien sind möglich. – Mjh

Antwort

1
  • INDEX(category, status, city)

  • Rethink hinzufügen Dumping, dass viele Daten aus - tun die Nutzer wirklich brauchen so viel Zeug?

  • Überdenken, wie "calc found rows" zu bekommen - entweder entfernen Sie es von der Benutzeroberfläche, oder schauen Sie in Möglichkeiten der Zwischenspeicherung und/oder Annäherung an den Wert.

  • Überdenken Sie, ob Sie wirklich brauchen t.description, a.description - die JOINs sind Leistung (einige) zu verletzen.

(Und, wie bereits erwähnt, kann die Abfrage-Cache die Timings verwirrend sein. Durch einfaches Ändern LIMIT 0,50-LIMIT 0,51 das QC von treten in verhindern. Natürlich ist SQL_NO_CACHE besser.)

+0

t.description, eine Beschreibung, die etwas entdeckt haben muss! +1 – e4c5

+0

Sie nennen mich nicht superfreak für nichts. –

+0

Ok, ich laufe jetzt mit SQL_NO_CACHE und bekomme ständig 3,4 Sekunden. Wenn ich JOINs heraushole, bekomme ich 1 Sekunde weniger, aber immer noch 2,4 Sekunden. Making INDEX (Kategorie, Status, Stadt) schneiden Sie eine weitere Sekunde nach unten. Aber die Einnahme von CALC_FOUND_ROWS hat den meisten Effekt erzeugt und hat es auf 0,003 Sekunden gebracht, was perfekt ist. Während ich Daten aus anderen Tabellen zu einem einzigen duplizieren kann, um JOINs zu vermeiden, müsste ich etwas für dieses CALS_FOUND_ROWS herausfinden, das vom JQuery-Datatable-Plugin verwendet wird. Vielen Dank. – user164863

-2

Sie müssen die Datei my.ini ändern, um die langsamen Abfragen zu erfassen. gibt es folgende Parameter, die Sie

  1. slow_query_log es ON
  2. log_slow_queries = 5 sein sollte einrichten müssen; (Das bedeutet, dass MySQL-Abfragen protokolliert, die mehr als 5 Sekunden dauert)

Danke, Rakesh

+0

das OP hat es bereits eingerichtet, nur fragen, warum es nur manchmal langsam ist – e4c5

+1

Downvote Grund - Sie nicht die Frage zu lesen, so dass Sie etwas völlig anderes als Antwort zur Verfügung gestellt . Ich schlage vor, dass Sie dies löschen. – Mjh