Điều này là do những gì tôi gọi là quy tắc 5% dựa trên tập hợp khóa (tuple cardinality).
Nếu bạn lập chỉ mục một bảng có số lượng lệch nhau tồn tại, trình tối ưu hóa truy vấn MySQL sẽ luôn chọn đường dẫn có ít kháng cự nhất.
VÍ DỤ:Nếu một bảng có cột giới tính, số lượng thẻ là hai, M và F.
Bạn index cột giới tính như vậy là sao ??? Bạn hoàn toàn có thể nhận được hai danh sách liên kết khổng lồ.
Nếu bạn tải một triệu hàng vào bảng có cột giới tính, bạn có thể nhận được 50% M và 50% F.
Chỉ mục sẽ trở nên vô dụng trong quá trình tối ưu hóa truy vấn nếu số lượng của một tổ hợp khóa (tổng số khóa như tôi đã diễn đạt) nhiều hơn 5% tổng số bảng.
Bây giờ, đối với ví dụ của bạn, tại sao hai kế hoạch GIẢI THÍCH khác nhau ??? Tôi đoán là MySQL Query Optimizer và InnoDB với tư cách là một nhóm thẻ.
Trong TẠO BẢNG đầu tiên, bảng và các chỉ mục có cùng kích thước mặc dù nhỏ, vì vậy nó quyết định có lợi cho chỉ mục bằng cách thực hiện quét chỉ mục chứ không phải quét toàn bộ bảng . Hãy nhớ rằng các chỉ mục không phải là duy nhất mang theo khóa chính bên trong (RowID) của mỗi hàng trong các mục nhập chỉ mục của nó, do đó làm cho các chỉ mục có cùng kích thước với chính bảng đó.
Trong TẠO BẢNG thứ hai, do giới thiệu một cột khác, người dùng bây giờ bạn làm cho Trình tối ưu hóa Truy vấn thấy một tình huống hoàn toàn khác:Bảng hiện lớn hơn so với các chỉ mục . Do đó, Trình tối ưu hoá Truy vấn trở nên chặt chẽ hơn trong việc giải thích cách sử dụng các chỉ mục có sẵn. Nó đi đến quy tắc 5% mà tôi đã đề cập trước đây. Quy tắc đó đã thất bại thảm hại và Trình tối ưu hóa Truy vấn đã quyết định ủng hộ việc quét toàn bộ bảng.
