Mám podezření, že pomalost spočívá v načítání řádků, počtu vracených řádků, spíše než 5000+ vazebných zástupných symbolů v příkazu. pId IN ( ? , ? , ... , ? )
Můj návrh by byl otestovat vrácení pouze jednoho řádku, zadat jednu hodnotu, o které je známo, že existuje/vrátit řádek, a poté 4999+ hodnot, o kterých je známo, že neexistují/nevrací řádek.
Pokud například známe nejvyšší hodnotu pId v tabulce, použijte vyšší hodnoty, zadejte hodnoty vazby pro příkaz jako je tento
... pId IN ( ? , ? , ? , ... , ? )
takže výsledek by byl ekvivalentní běhu
... pId IN ( 99999999 , 99999998 , 99999997 , ... , 42 )
což by byl stejný výsledek, jaký bychom spustili
... pId IN ( 42 )
Naše očekávání by bylo vrátit pouze jeden řádek (pId =42).
Poté porovnejte načasování toho ( 5000+ vazebných hodnot vracejících 1 řádek) se dvěma vázanými hodnotami vracejícími jeden řádek
... pId IN ( 99999999 , 42 )
A zjistěte, zda existuje významný rozdíl ve výkonu.
(S více než 5000 hodnotami vazeb je potřeba více práce, ale neočekával bych obrovské rozdíl, ale měl by být otestován.
Když se nad tím trochu zamyslíte, mohlo by být snazší nastavit test pomocí všech existujících hodnot vazby a pouze přidat LIMIT 2 na konec dotazu. (Nejsem si jistý, zda má MySQL nějaká vylepšení výkonu pro LIMIT 2 .
Možná bude lepší přidat podmínku jako AND pId * 10 = 420
Cílem je poskytnout celou řadu hodnot vazeb, ale vrátit pouze jeden nebo dva řádky.
Dalším testem by bylo vrátit celou řadu řádků, ale s použitím pouze několika hodnot vazby. Možná podmínka rozsahu, která vrátí 5000+ řádků.
Dotaz může být:
... pId >= ? AND pId <= ?
s dostatečně velkým rozsahem mezi poskytnutými hodnotami, které dostaneme v blízkosti 5000 řádků.
A porovnejte výkon.
Moje předpověď (hádám?) je, že výkon bude korelovat spíše s počtem vrácených řádků než s počtem hodnot vazby.
Nejsem si jistý, zda je to odpověď na vaši otázku, ale je to přístup, který bych zvolil, abych odpověděl na otázku ... "co způsobuje, že je to pomalé, počet hodnot vazby nebo počet vrácených řádků? "
."