Vertrouw op de optimizer.
Schrijf de zoekopdracht die het eenvoudigst uitdrukt wat u probeert te bereiken. Als je hebt prestatieproblemen met die query, dan moet je kijken of er indexen ontbreken. Maar u hoeft dit nog steeds niet expliciet te doen werk met deze indexen.
Maak je geen zorgen over hoe je zou zo'n zoekopdracht kunnen implementeren.
In zeer In zeldzame gevallen kan het nodig zijn om de zoekopdracht verder te forceren om bepaalde indexen te gebruiken (via hints), maar dit is waarschijnlijk <0,1% van de zoekopdrachten.
In uw geposte plannen veroorzaakt uw "geoptimaliseerde" versie scans tegen 2 indexen van uw (ik neem aan) Params-tabel (PK_Params_1, IX_Params_1). Zonder de query's te zien, is het moeilijk om te weten waarom dit gebeurt, maar als je vergelijkt met het hebben van een enkele scan tegen een tabel ("Brute force") en twee, is het gemakkelijk in te zien waarom de tweede niet efficiënter is.
Ik denk dat ik het zou proberen:
SELECT p.ProductID, ptr.[Rank]
FROM dbo.SearchItemsGet(@SearchID, NULL) AS si
JOIN dbo.ProductDefs AS pd
ON pd.ParamTypeID = si.ParamTypeID
JOIN dbo.Params AS p
ON p.ProductDefID = pd.ProductDefID
JOIN dbo.ProductTypesResultsGet(@SearchID) AS ptr
ON ptr.ProductTypeID = pd.ProductTypeID
LEFT JOIN Params p_anti
on p_anti.ProductDefId = pd.ProductDefID and
(p_anti.ParamLo < si.LowMin or p_anti.ParamHi > si.HiMax)
WHERE si.Mode IN (1, 2)
AND p_anti.ProductID is null
GROUP BY p.ProductID, ptr.[Rank]
D.w.z. introduceer een anti-join die de resultaten elimineert die je niet wilt.