Đó là cách mọi thứ diễn ra. Chờ tôi một phút ...
Trình tối ưu hóa muốn sử dụng INDEX, trong trường hợp này là ACTI_DATE_I. Nhưng nó không muốn sử dụng nếu điều đó sẽ chậm hơn.
Kế hoạch A:Sử dụng chỉ mục.
- Tiếp cận chỉ mục có cấu trúc BTree ở cuối (vì DESC)
- Quét ngược
- Đối với mỗi hàng trong chỉ mục, hãy tra cứu hàng tương ứng trong dữ liệu. Lưu ý:Chỉ mục có (ACTIVITY_DATE, ACTIVITY_ID) vì KHÓA CHÍNH được thêm vào bất kỳ khóa phụ nào. Để tiếp cận "dữ liệu" bằng PK (ACTIVITY_ID) là một cách tra cứu BTree khác, có thể là ngẫu nhiên. Do đó, nó có khả năng chậm. (Nhưng không chậm lắm trong trường hợp của bạn.)
- Điều này dừng lại sau LIMIT hàng.
Kế hoạch B:Bỏ qua bảng
- Quét bảng, tạo bảng tmp. (Có thể là trong bộ nhớ.)
- Sắp xếp bảng tmp
- Gỡ bỏ LIMIT hàng.
Trong trường hợp của bạn (96 - 1% của 10K), thật đáng ngạc nhiên là nó đã chọn quét bảng. Thông thường, giới hạn nằm ở khoảng 10% -30% số hàng trong bảng.
ANALYZE TABLE nên đã thực hiện tính toán lại thống kê, điều này có thể đã thuyết phục nó thực hiện với Kế hoạch khác.
Bạn đang sử dụng phiên bản MySQL nào? (Không, tôi không biết bất kỳ thay đổi nào trong lĩnh vực này.)
Một điều bạn có thể thử:OPTIMIZE TABLE ACTIVITIES; Điều đó sẽ xây dựng lại bảng, do đó đóng gói lại các khối và dẫn đến tiềm năng thống kê khác nhau. Nếu điều đó hữu ích, tôi muốn biết điều đó - vì tôi thường nói "Bảng tối ưu hóa là vô dụng".
