MySQL:Seleziona l'esecuzione della query e il tempo di recupero dei risultati aumenta con il numero di connessioni

Probabilmente ogni connessione sta eseguendo una scansione completa della tabella di profiles . Cerchiamo di evitarlo. Quando ci sono dozzine di query che colpiscono la stessa tabella, ci sono blocchi che fanno "inciampare su se stesso" InnoDB. Uno di questi piani velocizzerà la query e diminuirà il numero di righe toccate (quindi diminuirà il blocco). L'uso dell'indice "composito" suggerito accelererà la query. Ma il OR si mette di mezzo. Vedo due trucchi per avere ancora un'occhiata all'indice su uniquestring , ma evita alcuni o tutti gli OR .

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

OR è difficile da ottimizzare.

Aggiungi questo:

INDEX(isconnected, isprofilepresent, uniquestring)

Allora...

Piano A:

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

Ciò presuppone che tu possa costruire quel prefisso comune.

Piano B (girare 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

Il piano A (se pratico) sfrutta ciò che sembra essere un valore di partenza comune. Il piano B funziona a prescindere, ma probabilmente è un po' più lento, anche se comunque molto più veloce dell'originale.

Altre note...

Gli indici sui flag (di cui ne hai due) non vengono quasi mai utilizzati. EXPLAIN SELECT ... probabilmente mostrerà che nessuno dei due è stato utilizzato. Si prega di fornire il EXPLAIN per qualsiasi SELECT che ha bisogno di discussione.

Una UNIQUE KEY è una KEY , quindi non è necessario l'indice ridondante su USERID .

limit 450 -- Quale 450 vuoi? Senza un ORDER BY , la query può fornirti qualsiasi 450. (Certo, forse va bene.) (E ORDER BY probabilmente rallenterebbe la query.)

I miei suggerimenti non "risolveranno" il problema, ma dovrebbero aumentare il numero di connessioni prima che il rallentamento diventi evidente.