Всъщност вашият първичен ключ няма никакъв смисъл по отношение на такава заявка за диапазон. Той посочва само уникални двойки за <from_ip, to_ip> кортеж - по този начин MySQL няма да може да използва този индекс с подобни сравнения на диапазони.
Освен ако не изпълнявате някаква заявка, която включва и двете части на вашия първичен ключ, тя няма да има ефект (е, всъщност MySQL също ще го използва - когато условието за избор използва ляво подмножество на съставния индекс , но това не е вашият случай). Например, това ще използва първичен ключ:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
Във вашия случай съставният ключ може да е първичен ключ, да, но единственото предимство ще бъде - да осигури уникалност. Така че можете да го оставите такъв, какъвто е, или да създадете сурогатен id първичен ключ (замяна на текущия първичен ключ с UNIQUE ограничение).
Едно от възможните решения за подобряване на ситуацията може да бъде - създаване на ключове с една колона за from_ip и to_ip . Тъй като те са цели числа, има добър шанс за висока мощност, която индексите на резултата ще имат. Въпреки това, MySQL може да използва само един индекс и следователно ще загубите „половината“ от ефективно сравнение на диапазона. Също така трябва да запомните, че ако сравнението по-голямо от (или по-малко от) ще засегне твърде много редове, MySQL ще не използвайте и индекс (тъй като очевидно няма смисъл от това, защото има твърде много редове за избор).
И - да, избягвайте използването на функции в WHERE клауза. Не казвам, че MySQL винаги ще загуби използването на индекса в такъв случай (но най-вероятно ще го загуби в повечето случаи) - но помислете за допълнителни разходи, които ще предизвикат извикване на функция. Дори и да е малко - винаги можете да се отървете от него, като подадете правилна стойност, формирана от вашето приложение.
