Is er een prestatieverschil tussen TUSSEN en IN met MySQL of in SQL in het algemeen?

BETWEEN moeten beter presteren dan IN in dit geval (maar doe meet en controleer ook uitvoeringsplannen!), vooral als n groeit en omdat de statistieken nog steeds kloppen. Laten we aannemen:

• m is de grootte van je tafel
• n is de grootte van je assortiment

Index kan worden gebruikt (n is klein vergeleken met m )

• In theorie, BETWEEN kan worden geïmplementeerd met een enkele "bereikscan" (Oracle speak) op de primaire sleutelindex, en vervolgens maximaal n doorlopen index blad knooppunten. De complexiteit is O(n + log m)

• IN wordt meestal geïmplementeerd als een reeks (lus) van n "bereikscans" op de primaire sleutelindex. Met m aangezien de tabel zo groot is, is de complexiteit altijd O(n * log m) ... wat altijd erger is (verwaarloosbaar voor zeer kleine tabellen m of zeer kleine bereiken n )

Index kan niet worden gebruikt (n is een aanzienlijk deel van m )

In ieder geval krijgt u een volledige tabelscan en evalueert u het predikaat op elke rij:

• BETWEEN moet twee predikaten evalueren:een voor de ondergrens en een voor de bovengrens. De complexiteit is O(m)

• IN moet maximaal n . evalueren predikaten. De complexiteit is O(m * n) ... wat weer altijd erger is, of misschien O(m) als de database de IN . kan optimaliseren lijst om een ​​hashmap te zijn, in plaats van een lijst met predikaten.