En realidad, su clave principal tiene poco sentido en términos de consulta de rango. Solo indica pares únicos para <from_ip, to_ip> tupla:por lo tanto, MySQL no podrá usar ese índice con tales comparaciones de rango.
A menos que esté ejecutando alguna consulta que involucre ambas partes de su clave principal, no tendrá ningún efecto (bueno, en realidad, MySQL también la usará, cuando la condición de selección use subconjunto izquierdo del índice compuesto , pero ese no es tu caso). Por ejemplo, esto usará la clave principal:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
En su caso, la clave compuesta puede ser la clave principal, sí, pero su único beneficio será proporcionar unicidad. Por lo tanto, puede dejarlo como está o crear un id sustituto clave principal (reemplazando la clave principal actual con UNIQUE restricción).
Una de las posibles soluciones para mejorar la situación podría ser:crear claves de una sola columna para from_ip y to_ip . Dado que son números enteros, existe una buena probabilidad de alta cardinalidad que tendrán los índices de resultados. Sin embargo, MySQL puede usar solo un índice y, por lo tanto, perderá 'la mitad' de la comparación eficiente del rango. También debe recordar que si la comparación mayor que (o menor que) afectará a demasiadas filas, MySQL lo hará. no use el índice también (ya que, obviamente, no tiene sentido porque hay demasiadas filas para seleccionar).
Y, sí, evita usar funciones en WHERE cláusula. No estoy diciendo que MySQL siempre perderá el uso del índice en tal caso (pero lo más probable es que lo pierda en la mayoría de los casos), pero piense en los gastos generales que causarán la llamada a la función. Incluso si es pequeño, siempre puede deshacerse de él pasando el valor correcto, formado por su aplicación.
