Eigentlich hat Ihr Primärschlüssel in Bezug auf eine solche Bereichsabfrage wenig Sinn. Es gibt nur eindeutige Paare für <from_ip, to_ip> an Tupel - daher kann MySQL diesen Index nicht mit solchen Bereichsvergleichen verwenden.
Wenn Sie keine Abfrage ausführen, die beide Teile Ihres Primärschlüssels umfasst, hat dies keine Auswirkung (na ja, MySQL wird ihn auch verwenden - wenn die Auswahlbedingung linke Teilmenge des zusammengesetzten Indexes , aber das ist nicht dein Fall). Dies verwendet beispielsweise den Primärschlüssel:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
In Ihrem Fall kann der zusammengesetzte Schlüssel der Primärschlüssel sein, ja, aber der einzige Vorteil besteht darin, Eindeutigkeit bereitzustellen. Sie können es also so lassen, wie es ist, oder eine Ersatz-id erstellen Primärschlüssel (Ersetzen des aktuellen Primärschlüssels durch UNIQUE Zwang).
Eine der möglichen Lösungen zur Verbesserung der Situation könnte sein:Erstellen Sie einspaltige Schlüssel für from_ip und to_ip . Da es sich um ganze Zahlen handelt, besteht eine gute Chance für eine hohe Kardinalität, die Ergebnisindizes haben werden. MySQL kann jedoch nur einen Index verwenden, und daher verlieren Sie die „Hälfte“ des bereichseffizienten Vergleichs. Außerdem sollten Sie bedenken, dass MySQL dies tut, wenn der Größer-als- (oder Kleiner-als-) Vergleich zu viele Zeilen betrifft Verwenden Sie nicht auch den Index (da dies offensichtlich keinen Sinn macht, da zu viele Zeilen ausgewählt werden müssen).
Und - ja, vermeiden Sie die Verwendung von Funktionen in WHERE Klausel. Ich sage nicht, dass MySQL in einem solchen Fall immer die Indexnutzung verliert (aber höchstwahrscheinlich wird es sie in den meisten Fällen verlieren) - aber denken Sie an den Overhead, der einen Funktionsaufruf verursacht. Auch wenn es wenig ist - Sie können es immer loswerden, indem Sie den richtigen Wert übergeben, der von Ihrer Anwendung gebildet wird.
