Việc tạo một chỉ mục trên thuộc tính BIT (n) trong MySQL có hợp lý không?


7

Tôi đang làm việc trên một điều rất cụ thể và tôi cần sử dụng BIT(n)các thuộc tính và tìm kiếm hiệu quả thông qua chúng. nnói chung không phải là sức mạnh của 2.

Tôi đã thấy một số đề cập trên internet rằng BITcác thuộc tính không thân thiện với chỉ mục trong MySQL. Không có công phu hơn mặc dù.

Vì vậy, câu hỏi là - các chỉ mục MySQL có hoạt động tốt với BIT(n)các thuộc tính hay tốt hơn là tôi tìm một số cách khác, như hạn chế n, nói, 32 và sử dụng INTthay thế?

Câu trả lời:


6

Trừ khi bạn đang truy vấn một kết quả khớp chính xác trên toàn bộ giá trị được lưu trữ trong cột bit, một chỉ mục sẽ không có ích, bởi vì nó thường không thể được sử dụng. Nếu bạn có cơ hội từ xa, thì nó sẽ như vậy.

Các lý do không thể sử dụng chỉ mục khi lưu trữ giá trị bitmap và sau đó truy vấn dựa trên trạng thái của một hoặc nhiều bit bao gồm thực tế là các loại chỉ mục thường có trong MySQL chỉ hữu ích cho khớp chính xác hoặc giá trị phạm vi và so sánh bitwise không thực sự là một trong những điều đó.

Do tính chất của giới hạn này, nó cũng đúng nếu bạn sử dụng bất kỳ loại dữ liệu số nguyên hoặc thậm chí loại dữ liệu SET.

Chẳng hạn, việc kiểm tra trạng thái của bit cao trên số 8 bit cũng giống như kiểm tra xem số đó có> = 128 hay không, có thực sự là một phạm vi khớp và có thể được thực hiện bằng chỉ số b-tree, nhưng sử dụng một chỉ mục cho thử nghiệm này, trình tối ưu hóa sẽ phải hiểu rằng đây là điều bạn "thực sự" hỏi khi điều bạn thực sự yêu cầu là WHERE bin_col & b'10000000 '... trình tối ưu hóa sẽ không nhận ra cái đó.

Xu hướng lưu trữ các giá trị bitmap của tôi sẽ là sử dụng cột INT KHÔNG ĐƯỢC KÝ [một cái gì đó], vì các cột BIT trong MySQL thực sự giống với các cột CHAR / BINARY hơn là dữ liệu số nguyên, nhưng điều này cuối cùng sẽ phụ thuộc vào ứng dụng của bạn cũng như công cụ lưu trữ của bạn.

MyISAM rõ ràng lưu trữ các cột bit khác nhau cùng nhau trong dữ liệu hàng thô, vì vậy nếu bạn không sử dụng số gia chẵn của 8/16 / 32/64, có thể có một lợi thế lưu trữ nhỏ ở đó khi sử dụng BIT so với INT - nhưng trừ khi bạn ' Đang sử dụng MyISAM, tôi không nghĩ rằng điều này sẽ đủ lợi thế để khiến bạn cân nhắc sử dụng nó.

Các công cụ MEMORY và InnoDB phân bổ kích thước số nguyên chuẩn nhỏ nhất có thể chứa số bit cần thiết trong một cột BIT.

Kiểu dữ liệu SET cũng lưu trữ các giá trị dưới dạng số nguyên không dấu 1, 2, 3, 4 hoặc 8 byte, theo yêu cầu của số lượng nhãn bạn xác định cho các bit. Sẽ dễ dàng hơn trên nhãn cầu khi bạn nhìn vào dữ liệu bitmap được lưu trữ của mình, bởi vì nếu bạn chọn từ nó mà không đưa kết quả trở lại thành một số nguyên (rõ ràng hoặc ẩn với SELECT cột_name + 0), bạn sẽ nhận được một dấu phẩy được phân tách bằng dấu phẩy danh sách các nhãn của các bit được đặt thành 'trên' ... Nó không cung cấp bất kỳ tối ưu hóa nào trong truy vấn nhưng nó giúp bạn tăng cường mở rộng các bit của mình thành nhãn mà không bị phạt thực sự so với sử dụng số nguyên thô cột.


Cảm ơn câu trả lời chi tiết này! Có, tôi hiểu rằng b-tree sẽ không thể giúp tìm kiếm các giá trị bằng vị ngữ có chứa các hoạt động bitwise. Mặc dù tôi không chắc chắn về cách MySQL lưu trữ BITattrs trong InnoDB (xin lỗi, tôi đã quên đề cập đến việc tôi đang sử dụng InnoDB) và nó có ảnh hưởng đến việc lập chỉ mục hay không. Trong thực tế, theo câu trả lời của bạn, có vẻ như sử dụng BITthay vì các loại số khác có lợi thế duy nhất - thuận tiện nếu bạn cần một số bit khác với sức mạnh là 2.
bazzilic
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.