Zaufaj optymalizatorowi.
Napisz zapytanie, które najprościej wyraża to, co chcesz osiągnąć. Jeśli masz problemy z wydajnością z tym zapytaniem, powinieneś sprawdzić, czy nie ma brakujących indeksów. Ale nadal nie powinieneś wyraźnie pracuj z tymi indeksami.
Nie przejmuj się rozważaniami o tym, jak ty może zaimplementować takie wyszukiwanie.
W bardzo W rzadkich przypadkach może być konieczne dalsze wymuszenie użycia w zapytaniu określonych indeksów (poprzez podpowiedzi), ale prawdopodobnie jest to <0,1% zapytań.
W opublikowanych planach Twoja „zoptymalizowana” wersja powoduje skanowanie 2 indeksów Twojej (przypuszczam) tabeli Params (PK_Params_1, IX_Params_1). Bez oglądania zapytań trudno jest zrozumieć, dlaczego tak się dzieje, ale jeśli porównujesz z pojedynczym skanowaniem tabeli ("Brute force") i dwoma, łatwo zrozumieć, dlaczego drugi nie jest bardziej wydajny.
Myślę, że spróbuję:
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]
Tj. wprowadź zabezpieczenie przed sprzężeniem, które eliminuje niepożądane rezultaty.
