Først skal du kontrollere, at sorteringen faktisk er en flaskehals i ydeevnen. Varigheden af sorteringen vil afhænge af antallet af elementer, der skal sorteres, og antallet af butikker for en bestemt overordnet butik vil sandsynligvis være lille. (Det forudsætter, at sorteringsoperatoren anvendes efter anvendelse af where-klausulen).
Det er en overgeneralisering. Ofte kan en sorteringsoperator trivielt flyttes ind i indekset, og hvis kun de første par rækker af resultatsættet hentes, kan det reducere forespørgselsomkostningerne væsentligt, fordi databasen ikke længere skal hente alle matchende rækker (og sortere dem) alle) for at finde de første, men kan læse posterne i resultatsæt rækkefølge og stoppe, når der er fundet nok poster.
I dit tilfælde ser det ud til, at du henter hele resultatsættet, så sortering, der er usandsynligt, vil gøre tingene meget værre (medmindre resultatsættet er enormt). Også i dit tilfælde er det måske ikke trivielt at bygge et nyttigt sorteret indeks, fordi where-sætningen indeholder et eller.
Nu, hvis du stadig ønsker at slippe af med den sorteringsoperatør, kan du prøve:
SELECT [Phone]
FROM [dbo].[Store]
WHERE [ParentStoreId] = 10
AND [Type] in (0, 1)
ORDER BY [Phone]
Alternativt kan du prøve følgende indeks:
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Phone], [Type])
for at prøve at få forespørgselsoptimeringsværktøjet til at lave en indeksområdescanning på ParentStoreId kun, scan derefter alle matchende rækker i indekset, udskriv dem, hvis Type Tændstikker. Dette vil dog sandsynligvis forårsage mere disk I/O, og dermed sænke din forespørgsel i stedet for at fremskynde den.
Rediger :Som en sidste udvej kan du bruge
SELECT [Phone]
FROM [dbo].[Store]
WHERE [ParentStoreId] = 10
AND [Type] = 0
ORDER BY [Phone]
UNION ALL
SELECT [Phone]
FROM [dbo].[Store]
WHERE [ParentStoreId] = 10
AND [Type] = 1
ORDER BY [Phone]
med
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Type], [Phone])
og sorter de to lister på applikationsserveren, hvor du kan flette (som i flettesortering) de forudsorterede lister og derved undgå en fuldstændig sortering. Men det er virkelig en mikro-optimering, der, selv om den fremskynder selve sorteringen med en størrelsesorden, sandsynligvis ikke vil påvirke den samlede udførelsestid af forespørgslen meget, da jeg ville forvente, at flaskehalsen er netværk og disk I/O, især i lyset af det faktum, at disken vil gøre meget tilfældig adgang, da indekset ikke er klynget.