De ORDER BY
moet de resultatenset sorteren, wat lang kan duren als deze groot is.
Om het te optimaliseren, moet u de tabellen mogelijk correct indexeren.
Het indextoegangspad heeft echter zijn nadelen, dus het kan zelfs langer duren.
Als je iets anders hebt dan equijoins in je zoekopdracht, of de ranged-predikaten (zoals <
, >
of BETWEEN
, of GROUP BY
clausule), dan de index die wordt gebruikt voor ORDER BY
kan voorkomen dat de andere indexen worden gebruikt.
Als u de zoekopdracht plaatst, kan ik u waarschijnlijk vertellen hoe u deze kunt optimaliseren.
Bijwerken:
Herschrijf de vraag:
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
De relatie View_Product_Joined
, zoals de naam al doet vermoeden, is waarschijnlijk een uitzicht.
Kun je de definitie ervan posten?
Als het indexeerbaar is, kunt u profiteren van het maken van een index op View_Product_Joined (SiteName, Published, DocumentCulture, SKUEnabled, NodeOrder)
.