MySQL :sélectionnez l'exécution de la requête et le temps de récupération des résultats augmente avec le nombre de connexions

Probablement que chaque connexion effectue une analyse complète de la table des profiles . Essayons d'éviter cela. Lorsqu'il y a des dizaines de requêtes qui frappent la même table, il y a des verrous qui font qu'InnoDB « trébuche sur lui-même ». L'un ou l'autre de ces plans accélérera la requête et diminuera le nombre de lignes touchées (diminuera donc le verrouillage). L'utilisation de l'index "composite" suggéré accélérera la requête. Mais le OR est dans la manière. Je vois deux astuces pour toujours avoir un index regarder uniquestring , mais évitez tout ou partie des OR .

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

OR est difficile à optimiser.

Ajoutez ceci :

INDEX(isconnected, isprofilepresent, uniquestring)

Alors...

Régime A :

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

Cela suppose que vous pouvez construire ce préfixe commun.

Plan B (tournez OR en 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

Le plan A (si possible) tire parti de ce qui semble être une valeur de départ commune. Le plan B fonctionne malgré tout, mais est probablement un peu plus lent, bien que toujours beaucoup plus rapide que l'original.

Autres remarques...

Les index sur les drapeaux (dont vous en avez deux) ne sont presque jamais utilisés. EXPLAIN SELECT ... montrera probablement que ni l'un ni l'autre n'a été utilisé. Veuillez fournir l'EXPLAIN pour tout SELECT qui a besoin de discussion.

Une UNIQUE KEY est une KEY , il n'y a donc pas besoin de l'index redondant sur USERID .

limit 450 -- Quel 450 voulez-vous? Sans ORDER BY , la requête est autorisée à vous donner tout 450. (Bien sûr, peut-être que c'est bien.) (Et ORDER BY ralentirait probablement la requête.)

Mes suggestions ne "résoudront" pas le problème, mais elles devraient augmenter le nombre de connexions avant que le ralentissement ne devienne perceptible.