Trên thực tế, khóa chính của bạn có rất ít ý nghĩa đối với truy vấn phạm vi như vậy. Nó chỉ biểu thị các cặp duy nhất cho <from_ip, to_ip> tuple - do đó, MySQL sẽ không thể sử dụng chỉ mục đó với các so sánh phạm vi như vậy.
Trừ khi bạn đang chạy một số truy vấn liên quan đến cả hai phần của khóa chính của mình, nó sẽ không có tác dụng (thực ra, MySQL cũng sẽ sử dụng nó - khi điều kiện lựa chọn sử dụng left- bộ chỉ mục kết hợp , nhưng đó không phải là trường hợp của bạn). Ví dụ:điều này sẽ sử dụng khóa chính:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
Trong trường hợp của bạn, khóa ghép có thể là khóa chính, vâng, nhưng lợi ích duy nhất của nó là - cung cấp tính duy nhất. Vì vậy, bạn có thể để nguyên hoặc tạo id thay thế khóa chính (thay thế khóa chính hiện tại bằng UNIQUE hạn chế).
Một trong những giải pháp khả thi để cải thiện tình hình có thể là - tạo các khóa cột đơn cho from_ip và to_ip . Vì chúng là các số nguyên, nên có một cơ hội tốt để có số lượng thẻ số cao, các chỉ mục kết quả sẽ có. Tuy nhiên, MySQL chỉ có thể sử dụng một chỉ mục và do đó, bạn sẽ mất 'một nửa' so sánh hiệu quả phạm vi. Ngoài ra, bạn nên nhớ rằng nếu so sánh lớn hơn (hoặc nhỏ hơn) sẽ ảnh hưởng đến quá nhiều hàng, MySQL sẽ cũng không sử dụng chỉ mục (vì rõ ràng là không có ý nghĩa gì vì có quá nhiều hàng để chọn).
Và - có, tránh sử dụng các hàm trong WHERE mệnh đề. Tôi không nói rằng MySQL sẽ luôn sử dụng chỉ mục lỏng lẻo trong trường hợp như vậy (nhưng rất có thể, nó sẽ mất nó trong hầu hết các trường hợp) - nhưng hãy nghĩ về chi phí sẽ gây ra lệnh gọi hàm. Ngay cả khi nó nhỏ - bạn luôn có thể loại bỏ nó bằng cách chuyển giá trị chính xác, được tạo bởi ứng dụng của bạn.
