Ve skutečnosti má váš primární klíč z hlediska takového dotazu na rozsah malý smysl. Označuje pouze jedinečné páry pro <from_ip, to_ip> n-tice - MySQL tedy nebude moci použít tento index pro takové srovnání rozsahů.
Pokud nespouštíte nějaký dotaz, který zahrnuje obě části vašeho primárního klíče, nebude to mít žádný účinek (no, ve skutečnosti ho použije i MySQL – když podmínka výběru používá levá podmnožina složeného indexu , ale to není váš případ). Například se použije primární klíč:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
Ve vašem případě může být složený klíč primárním klíčem, ano, ale jeho jedinou výhodou bude - poskytnout jedinečnost. Můžete jej tedy nechat tak, jak je, nebo vytvořit náhradní id primární klíč (nahrazení aktuálního primárního klíče UNIQUE omezení).
Jedním z možných řešení, jak situaci zlepšit, by mohlo být - vytvoření jednosloupcových klíčů pro from_ip a to_ip . Protože se jedná o celá čísla, existuje velká šance na vysokou mohutnost, kterou výsledné indexy budou mít. MySQL však může používat pouze jeden index, a proto ztratíte „polovinu“ efektivního porovnávání rozsahu. Také byste si měli pamatovat, že pokud porovnání větší než (nebo menší než) ovlivní příliš mnoho řádků, MySQL nepoužívejte také index (protože to samozřejmě nemá smysl, protože je příliš mnoho řádků na výběr).
A - ano, vyhněte se používání funkcí v WHERE doložka. Neříkám, že MySQL v takovém případě vždy ztratí využití indexu (ale s největší pravděpodobností jej ztratí ve většině případů) - ale myslete na režii, která způsobí volání funkce. I když je to málo – vždy se toho můžete zbavit předáním správné hodnoty vytvořené vaší aplikací.