To radikalt forskellige forespørgsler mod 4 mil records udføres på samme tid - den ene bruger brute force

Stol på optimeringsværktøjet.

Skriv den forespørgsel, der mest enkelt udtrykker, hvad du forsøger at opnå. Hvis du har ydelsesproblemer med den forespørgsel, så skal du se på, om der mangler nogle indekser. Men du burde stadig ikke være nødt til det eksplicit arbejde med disse indekser.

Bekymre dig ikke med overvejelser om hvordan du kan implementere en sådan søgning.

I meget I sjældne tilfælde skal du muligvis tvinge forespørgslen til at bruge bestemte indekser (via tip), men dette er sandsynligvis <0,1 % af forespørgslerne.

I dine opslåede planer forårsager din "optimerede" version scanninger mod 2 indekser af din (formoder jeg) Params-tabel (PK_Params_1, IX_Params_1). Uden at se forespørgslerne er det svært at vide, hvorfor dette sker, men hvis du sammenligner med at have en enkelt scanning mod en tabel ("Brute force") og to, er det let at se, hvorfor den anden ikke er mere effektiv.

Jeg tror, ​​jeg ville prøve:

        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]

dvs. indføre en anti-join, der eliminerer de resultater, du ikke ønsker.