Na verdade, sua chave primária tem pouco sentido em termos de consulta de intervalo. Indica apenas pares exclusivos para
<from_ip, to_ip> tupla - assim, o MySQL não poderá usar esse índice com tais comparações de intervalo. A menos que você esteja executando alguma consulta que envolva ambas as partes de sua chave primária, ela não terá efeito (bem, na verdade, o MySQL também a usará - quando a condição de seleção usar subconjunto esquerdo do índice composto , mas não é o seu caso). Por exemplo, isso usará a chave primária:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
No seu caso, a chave composta pode ser a chave primária, sim, mas o único benefício será - fornecer exclusividade. Então, você pode deixar como está ou criar um substituto
id chave primária (substituindo a chave primária atual por UNIQUE limitação). Uma das possíveis soluções para melhorar a situação poderia ser - criar chaves de coluna única para
from_ip e to_ip . Como eles são inteiros, há uma boa chance de alta cardinalidade, que os índices de resultado terão. No entanto, o MySQL pode usar apenas um índice e, portanto, você perderá 'metade' da comparação eficiente de intervalo. Além disso, lembre-se de que, se a comparação maior que (ou menor que) afetará muitas linhas, o MySQL não use índice também (já que, obviamente, não faz sentido isso porque há muitas linhas para selecionar). E - sim, evite usar funções em
WHERE cláusula. Não estou dizendo que o MySQL sempre perderá o uso do índice nesse caso (mas provavelmente o perderá na maioria dos casos) - mas pense na sobrecarga que causará a chamada de função. Mesmo que seja pouco - você sempre pode se livrar dele passando o valor correto, formado pela sua aplicação. 
