Le ORDER BY doit trier le jeu de résultats, ce qui peut prendre du temps s'il est volumineux.
Pour l'optimiser, vous devrez peut-être indexer les tables correctement.
Le chemin d'accès à l'index, cependant, a ses inconvénients et peut même prendre plus de temps.
Si vous avez autre chose que des équijointures dans votre requête, ou les prédicats étendus (comme < , > ou BETWEEN , ou GROUP BY clause), puis l'index utilisé pour ORDER BY peut empêcher l'utilisation des autres index.
Si vous publiez la requête, je pourrai probablement vous dire comment l'optimiser.
Mise à jour :
Réécrivez la requête :
SELECT *
FROM View_Product_Joined j
LEFT JOIN
[dbo].[OPR_InventoryRules] irp
ON irp.ID = j.skuid
AND irp.InventoryRulesType = 'Product'
LEFT JOIN
[dbo].[OPR_InventoryRules] irs
ON irs.ID = j.NodeSiteID
AND irs.InventoryRulesType = 'Store'
CROSS APPLY
(
SELECT TOP 1 *
FROM OPR_PriceLookup pl
WHERE pl.siteID = j.NodeSiteID
AND pl.skuid = j.skuid
AND pl.RoleID IN (-1, 13)
ORDER BY
pl.RoleID desc
) pl
WHERE SiteName = N'EcommerceSite'
AND Published = 1
AND DocumentCulture = N'en-GB'
AND NodeAliasPath LIKE N'/Products/Cats/Computers/Computer-servers/%'
AND NodeSKUID IS NOT NULL
AND SKUEnabled = 1
ORDER BY
NodeOrder ASC
La relation View_Product_Joined , comme son nom l'indique, est probablement une vue.
Pourriez-vous s'il vous plaît poster sa définition ?
S'il est indexable, vous pouvez bénéficier de la création d'un index sur View_Product_Joined (SiteName, Published, DocumentCulture, SKUEnabled, NodeOrder) .
