MySQL:Selecione a execução da consulta e o tempo de busca do resultado aumenta com o número de conexões

Provavelmente cada conexão está fazendo uma varredura completa da tabela de profiles . Vamos tentar evitar isso. Quando há dezenas de consultas atingindo a mesma tabela, há bloqueios que fazem com que o InnoDB "tropece em si mesmo". Qualquer um desses planos acelerará a consulta e diminuirá o número de linhas tocadas (portanto, diminuirá o bloqueio). O uso do índice "composto" sugerido irá acelerar a consulta. Mas o OR fica no caminho. Eu vejo dois truques para ainda ter uma visão de índice em uniquestring , mas evite alguns ou todos os OR .

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

OR é difícil de otimizar.

Adicione isso:

INDEX(isconnected, isprofilepresent, uniquestring)

Então...

Plano A:

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

Isso pressupõe que você possa construir esse prefixo comum.

Plano B (vire OR em 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

O Plano A (se prático) aproveita o que parece para ser um valor inicial comum. O Plano B funciona independentemente, mas provavelmente é um pouco mais lento, embora ainda muito mais rápido que o original.

Outras notas...

Índices em sinalizadores (dos quais você tem dois) quase nunca são usados. EXPLAIN SELECT ... provavelmente mostrará que nenhum dos dois foi usado. Forneça o EXPLAIN para qualquer SELECT que precisa de discussão.

Uma UNIQUE KEY é uma KEY , portanto, não há necessidade do índice redundante em USERID .

limit 450 -- Qual 450 você quer? Sem um ORDER BY , a consulta pode fornecer qualquer 450. (Claro, talvez isso seja bom.) (E ORDER BY provavelmente retardaria a consulta.)

Minhas sugestões não "resolverão" o problema, mas devem aumentar o número de conexões antes que a desaceleração se torne perceptível.