Nejprve byste měli ověřit, že řazení ve skutečnosti představuje problémové místo výkonu. Doba trvání řazení bude záviset na počtu prvků, které mají být seřazeny, a počet obchodů pro konkrétní nadřazený obchod bude pravděpodobně malý. (To za předpokladu, že se operátor řazení použije po aplikaci klauzule where).
To je přílišná generalizace. Operátor řazení lze často triviálně přesunout do indexu, a pokud se načte pouze prvních pár řádků sady výsledků, může to podstatně snížit náklady na dotaz, protože databáze již nemusí načítat všechny odpovídající řádky (a třídit je all), aby našel ty první, ale může číst záznamy v pořadí sady výsledků a zastavit se, jakmile bude nalezen dostatek záznamů.
Ve vašem případě se zdá, že načítáte celou sadu výsledků, takže je nepravděpodobné, že by třídění věci výrazně zhoršilo (pokud není sada výsledků obrovská). Ve vašem případě také nemusí být triviální vytvořit užitečný seřazený index, protože klauzule where obsahuje nebo.
Nyní, pokud se stále chcete zbavit tohoto operátora řazení, můžete zkusit:
SELECT [Phone]
FROM [dbo].[Store]
WHERE [ParentStoreId] = 10
AND [Type] in (0, 1)
ORDER BY [Phone]
Případně můžete zkusit následující index:
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Phone], [Type])
pokuste se přimět optimalizátor dotazů, aby provedl skenování rozsahu indexu na ParentStoreId
a poté prohledejte všechny odpovídající řádky v indexu a vytiskněte je, pokud Type
zápasy. Pravděpodobně to však způsobí více diskových I/O, a proto váš dotaz spíše zpomalí než zrychlí.
Upravit :Jako poslední možnost můžete použít
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]
s
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Type], [Phone])
a seřadit dva seznamy na aplikačním serveru, kde můžete sloučit (jako při slučovacím řazení) předtříděné seznamy, čímž se vyhnete úplnému řazení. Ale to je skutečně mikrooptimalizace, která sice řádově zrychlí samotné řazení, ale pravděpodobně příliš neovlivní celkovou dobu provádění dotazu, protože bych očekával, že úzkým hrdlem bude síť a diskové I/O, zejména ve světle skutečnosti, že disk bude mít mnoho náhodných přístupů, protože index není seskupený.