Có các cuộc thảo luận stackoverflow khác về cùng chủ đề này (các liên kết ở dưới cùng). Như đã lưu ý trong các nhận xét ở trên, nó có thể liên quan đến chỉ mục và trình tối ưu hóa bị nhầm lẫn và sử dụng sai.
Suy nghĩ đầu tiên của tôi là bạn đang thực hiện một dịch vụ hàng đầu được chọn từ (select * ....) và trình tối ưu hóa có thể gặp khó khăn khi đẩy truy vấn xuống các truy vấn bên trong và sử dụng chỉ mục.
Cân nhắc viết lại nó thành
select top 10 ServiceRequestID
from big_table_1
inner join big_table_2 cap2
on cap1.servicerequestid = cap2.customerreferencenumber
and big_table_1.statusid = 2
Trong truy vấn của bạn, cơ sở dữ liệu có thể đang cố gắng hợp nhất các kết quả và trả lại chúng và SAU ĐÓ giới hạn nó ở top 10 trong truy vấn bên ngoài. Trong truy vấn trên, cơ sở dữ liệu sẽ chỉ phải thu thập 10 kết quả đầu tiên vì các kết quả đang được hợp nhất, tiết kiệm rất nhiều thời gian. Và nếu servicerequestID được lập chỉ mục, nó sẽ chắc chắn sử dụng nó. Trong ví dụ của bạn, truy vấn đang tìm kiếm cột servicerequestid trong tập hợp kết quả đã được trả về ở định dạng ảo, không được lập chỉ mục.
Hy vọng điều đó có ý nghĩa. Mặc dù theo giả thuyết, trình tối ưu hóa phải sử dụng bất kỳ định dạng nào mà chúng tôi đặt SQL vào và tìm ra cách tốt nhất để trả về các giá trị mọi lúc, nhưng sự thật là cách chúng tôi đặt SQL lại với nhau có thể thực sự tác động đến thứ tự thực hiện các bước nhất định trên DB.
CHỌN HÀNG ĐẦU chậm, bất kể ĐƠN HÀNG THEO
Tại sao phần trên cùng (1) trên cột được lập chỉ mục trong SQL Server chậm?
