Confía en el optimizador.
Escriba la consulta que exprese de manera más simple lo que está tratando de lograr. Si tienes problemas de rendimiento con esa consulta, entonces debe ver si faltan índices. Pero aun así no deberías tener que explícitamente trabajar con estos índices.
No se preocupe por consideraciones de cómo usted podría implementar tal búsqueda.
En muy En circunstancias excepcionales, es posible que deba forzar aún más la consulta para que use índices particulares (a través de sugerencias), pero esto probablemente sea <0.1% de las consultas.
En sus planes publicados, su versión "optimizada" está causando escaneos en 2 índices de su (supongo) tabla Params (PK_Params_1, IX_Params_1). Sin ver las consultas, es difícil saber por qué sucede esto, pero si compara con tener un solo escaneo contra una tabla ("Fuerza bruta") y dos, es fácil ver por qué el segundo no es más eficiente.
Creo que intentaría:
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]
Es decir. introduzca un anti-join que elimine los resultados que no desea.
