Има и други дискусии на stackoverflow по същата тема (връзки в долната част). Както беше отбелязано в коментарите по-горе, това може да има нещо общо с индексите и оптимизатора, който се обърква и използва грешен.
Първата ми мисъл е, че правите избран най-висок идентификатор на услугата от (изберете *....) и оптимизаторът може да има затруднения да изтласка заявката надолу към вътрешните заявки и да използва индекса.
Помислете да го пренапишете като
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
Във вашата заявка базата данни вероятно се опитва да обедини резултатите и да ги върне и ТОГАВА да я ограничи до първите 10 във външната заявка. В горната заявка базата данни ще трябва да събере само първите 10 резултата, тъй като резултатите се обединяват, спестявайки много време. И ако servicerequestID е индексиран, той със сигурност ще го използва. Във вашия пример заявката търси колоната servicerequestid в набор от резултати, който вече е върнат във виртуален, неиндексиран формат.
Дано има смисъл. Докато хипотетично оптимизаторът трябва да вземе какъвто и формат да поставим SQL и да измисли най-добрия начин да връща стойности всеки път, истината е, че начинът, по който събираме нашия SQL заедно, може наистина да повлияе на реда, в който се извършват определени стъпки върху DB.
SELECT TOP е бавен, независимо от ORDER BY
Защо правенето на top(1) на индексирана колона в SQL Server е бавно?
