MySQL:de uitvoering van de query selecteren en de ophaaltijd van het resultaat neemt toe met het aantal verbindingen

Waarschijnlijk voert elke verbinding een volledige tabelscan uit van profiles . Laten we dat proberen te vermijden. Wanneer er tientallen vragen zijn die dezelfde tabel raken, zijn er vergrendelingen die ervoor zorgen dat InnoDB "over zichzelf struikelt". Elk van deze plannen zal zowel de zoekopdracht versnellen als het aantal aangeraakte rijen verminderen (en dus de vergrendeling verminderen). Het gebruik van de voorgestelde "samengestelde" index zal de zoekopdracht versnellen. Maar de OR staat in de weg. Ik zie twee trucjes om toch een index te bekijken op uniquestring , maar vermijd enkele of alle OR .

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

OR is moeilijk te optimaliseren.

Voeg dit toe:

INDEX(isconnected, isprofilepresent, uniquestring)

Dan...

Plan A:

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

Dit veronderstelt dat je dat gemeenschappelijke voorvoegsel kunt construeren.

Plan B (draai 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 (indien praktisch) maakt gebruik van wat lijkt een gemeenschappelijke startwaarde zijn. Plan B werkt hoe dan ook, maar is waarschijnlijk iets langzamer, hoewel nog steeds een stuk sneller dan het origineel.

Andere opmerkingen...

Indexen op vlaggen (waarvan je er twee hebt) worden bijna nooit gebruikt. EXPLAIN SELECT ... zal waarschijnlijk aantonen dat geen van beide werd gebruikt. Geef de EXPLAIN voor elke SELECT dat heeft discussie nodig.

EEN UNIQUE KEY is een KEY , dus er is geen overbodige index nodig op USERID .

limit 450 -- Welke 450 wil je? Zonder een ORDER BY , mag de zoekopdracht u elke . geven 450. (Natuurlijk is dat prima.) (En ORDER BY zou de zoekopdracht waarschijnlijk vertragen.)

Mijn suggesties zullen het probleem niet "oplossen", maar ze zouden het aantal verbindingen moeten verhogen voordat de vertraging merkbaar wordt.