実際、主キーはそのような範囲クエリに関してはほとんど意味がありません。 <from_ip, to_ip>の一意のペアのみを示します タプル-したがって、MySQLはそのような範囲比較でそのインデックスを使用できなくなります。
主キーの両方の部分を含むクエリを実行していない限り、効果はありません（実際、MySQLもそれを使用します-選択条件が複合インデックスの左サブセット 、しかしそれはあなたの場合ではありません）。たとえば、これは主キーを使用します：
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
あなたの場合、複合キーが主キーになる可能性がありますが、唯一の利点は、一意性を提供することです。したがって、そのままにすることも、代理のidを作成することもできます。 主キー（現在の主キーをUNIQUEに置き換えます 制約）。
状況を改善するための可能な解決策の1つは、次のとおりです。from_ipの単一列キーを作成する およびto_ip 。それらは整数であるため、カーディナリティが高くなる可能性が高く、その結果インデックスはそうなります。ただし、MySQLは1つのインデックスしか使用できないため、範囲効率の高い比較の「半分」が失われます。また、大なり（または小）の比較があまりにも多くの行に影響を与える場合、MySQLはインデックスも使用しないでください（行が多すぎて選択できないため、明らかに意味がありません）。
そして-はい、WHEREで関数を使用することは避けてください 句。このような場合、MySQLが常にインデックスの使用を失うと言っているわけではありません（ただし、ほとんどの場合、インデックスの使用が失われる可能性があります）。ただし、関数呼び出しの原因となるオーバーヘッドについて考えてみてください。たとえ少しでも、アプリケーションによって形成された正しい値を渡すことで、いつでもそれを取り除くことができます。