Pravděpodobně každé připojení provádí úplnou kontrolu tabulky profiles . Zkusme se tomu vyhnout. Když se na stejnou tabulku dostanou desítky dotazů, existují zámky, které způsobí, že InnoDB „zakopne sám o sebe“. Každý z těchto plánů urychlí dotaz a sníží počet dotčených řádků (tedy sníží zamykání). Použití navrhovaného „složeného“ indexu urychlí dotaz. Ale OR stojí v cestě. Vidím dva triky, jak mít stále přehled o uniquestring , ale vyhněte se některým nebo všem OR .
( (prfls.uniquestring like 'phk5600dcc%')
or (prfls.uniquestring like 'phk5600dcf%')
)
OR je těžké optimalizovat.
Přidejte toto:
INDEX(isconnected, isprofilepresent, uniquestring)
Pak...
Plán A:
prfls.uniquestring like 'phk5600dc%' AND -- note common prefix
( (prfls.uniquestring like 'phk5600dcc%')
or (prfls.uniquestring like 'phk5600dcf%')
)
To předpokládá, že dokážete vytvořit tuto společnou předponu.
Plán B (otočte OR do 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
Plán A (je-li praktický) využívá toho, co se zdá být běžnou výchozí hodnotou. Plán B funguje bez ohledu na to, ale je pravděpodobně trochu pomalejší, i když stále mnohem rychlejší než originál.
Další poznámky...
Indexy na vlajkách (které máte dva) se téměř nepoužívají. EXPLAIN SELECT ... pravděpodobně ukáže, že ani jedno nebylo použito. Zadejte prosím EXPLAIN pro jakýkoli SELECT to vyžaduje diskusi.
UNIQUE KEY je KEY , takže není potřeba redundantní index na USERID .
limit 450 -- Kterých 450 chcete? Bez ORDER BY , dotaz vám může poskytnout jakékoli 450. (Samozřejmě, možná je to v pořádku.) (A ORDER BY by pravděpodobně zpomalilo dotaz.)
Moje návrhy problém „nevyřeší“, ale měly by zvýšit počet připojení, než bude zpomalení patrné.