Mysql
 sql >> Datenbank >  >> RDS >> Mysql

MySQL:Die Ausführung ausgewählter Abfragen und die Zeit zum Abrufen der Ergebnisse nimmt mit der Anzahl der Verbindungen zu

Wahrscheinlich führt jede Verbindung einen vollständigen Tabellenscan von profiles durch . Versuchen wir das zu vermeiden. Wenn Dutzende von Abfragen dieselbe Tabelle treffen, gibt es Sperren, die dazu führen, dass InnoDB "über sich selbst stolpert". Jeder dieser Pläne beschleunigt sowohl die Abfrage als auch die Anzahl der berührten Zeilen (daher wird die Sperrung verringert). Die Verwendung des vorgeschlagenen "zusammengesetzten" Index beschleunigt die Abfrage. Aber das OR steht im Weg. Ich sehe zwei Tricks, um trotzdem einen Indexblick auf uniquestring zu haben , aber vermeiden Sie einige oder alle OR .

(      (prfls.uniquestring like 'phk5600dcc%')
   or  (prfls.uniquestring like 'phk5600dcf%')
)

OR ist schwer zu optimieren.

Fügen Sie dies hinzu:

INDEX(isconnected, isprofilepresent, uniquestring)

Dann...

Plan A:

prfls.uniquestring         like 'phk5600dc%' AND  -- note common prefix
(      (prfls.uniquestring like 'phk5600dcc%')
   or  (prfls.uniquestring like 'phk5600dcf%')
)

Dies setzt voraus, dass Sie dieses gemeinsame Präfix erstellen können.

Plan B (wende OR in UNION ):

( SELECT ...
    WHERE prfls.uniquestring like 'phk5600dcc%' AND ...
    LIMIT 450 )
UNION ALL    -- ? You may want DISTINCT, if there could be dups
( SELECT ...
    WHERE prfls.uniquestring like 'phk5600dcf%' AND ...  -- the only diff
    LIMIT 450 )
LIMIT 450   -- yes, again

Plan A (falls praktikabel) nutzt das, was scheint ein gemeinsamer Startwert sein. Plan B funktioniert trotzdem, ist aber wahrscheinlich etwas langsamer, aber immer noch viel schneller als das Original.

Andere Anmerkungen...

Indizes auf Flags (von denen Sie zwei haben) werden fast nie verwendet. EXPLAIN SELECT ... wird wahrscheinlich zeigen, dass keine von beiden verwendet wurde. Bitte geben Sie den EXPLAIN an für jeden SELECT das muss diskutiert werden.

Ein UNIQUE KEY ist ein KEY , daher ist der redundante Index auf USERID nicht erforderlich .

limit 450 -- Welche 450 willst du? Ohne ORDER BY , darf die Abfrage Ihnen beliebig geben 450. (Natürlich, vielleicht ist das in Ordnung.) (Und ORDER BY würde wahrscheinlich die Abfrage verlangsamen.)

Meine Vorschläge werden das Problem nicht "lösen", aber sie sollten die Anzahl der Verbindungen erhöhen, bevor die Verlangsamung spürbar wird.