Eigenlijk heeft uw primaire sleutel weinig zin in termen van een dergelijke bereikquery. Het geeft alleen unieke paren aan voor <from_ip, to_ip> tuple - dus MySQL zal die index niet kunnen gebruiken met dergelijke bereikvergelijkingen.
Tenzij u een query uitvoert die beide delen van uw primaire sleutel omvat, heeft het geen effect (nou ja, eigenlijk zal MySQL het ook gebruiken - wanneer de selectievoorwaarde linker-subset van samengestelde index , maar dat is niet jouw geval). Dit gebruikt bijvoorbeeld de primaire sleutel:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
In jouw geval kan de samengestelde sleutel de primaire sleutel zijn, ja, maar het enige voordeel zal zijn - om uniek te zijn. U kunt het dus laten zoals het is, of een surrogaat id . maken primaire sleutel (huidige primaire sleutel vervangen door UNIQUE beperking).
Een van de mogelijke oplossingen om de situatie te verbeteren zou kunnen zijn:maak sleutels met één kolom voor from_ip en to_ip . Omdat het gehele getallen zijn, is er een goede kans op een hoge kardinaliteit, die resultaatindexen zullen hebben. MySQL kan echter slechts één index gebruiken, en daarom verliest u 'de helft' van de bereik-efficiënte vergelijking. Houd er ook rekening mee dat als een groter-dan- (of minder-dan-)vergelijking van invloed is op te veel rijen, MySQL dat zal doen gebruik ook geen index (aangezien dat natuurlijk geen zin heeft omdat er te veel rijen zijn om te selecteren).
En - ja, vermijd het gebruik van functies in WHERE clausule. Ik zeg niet dat MySQL in dat geval altijd het indexgebruik zal verliezen (maar hoogstwaarschijnlijk zal het het in de meeste gevallen verliezen) - maar denk aan overhead die een functieaanroep zal veroorzaken. Zelfs als het weinig is, kun je er altijd vanaf komen door de juiste waarde door te geven, gevormd door je toepassing.