首先,您应该验证排序实际上是性能瓶颈。排序的持续时间将取决于要排序的元素的数量,并且特定父存储的存储数量可能很小。(这是假定在应用where子句之后应用了sort运算符)。
我听说排序运算符表示查询中的设计不正确,因为可以通过索引过早地进行排序
太笼统了。通常,可以将排序运算符平移到索引中,并且,如果仅获取结果集的前几行,则可以大大降低查询成本,因为数据库不再需要获取所有匹配的行(并对它们进行排序)全部)以查找第一个,但可以按结果集顺序读取记录,并在找到足够的记录后停止。
在您的情况下,您似乎正在获取整个结果集,因此排序不太可能使情况变得更糟(除非结果集很大)。另外,在您的情况下,构建有用的排序索引可能并不容易,因为where子句包含or。
现在,如果您仍然想摆脱该排序运算符,可以尝试:
SELECT [Phone]
FROM [dbo].[Store]
WHERE [ParentStoreId] = 10
AND [Type] in (0, 1)
ORDER BY [Phone]
或者,您可以尝试以下索引:
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Phone], [Type])
尝试让查询优化器ParentStoreId
仅对索引范围进行扫描,然后扫描索引中所有匹配的行,如果Type
匹配则将其输出。但是,这可能会导致更多的磁盘I / O,从而降低查询速度而不是加快查询速度。
:作为最后的手段,您可以使用
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]
和
CREATE NONCLUSTERED INDEX IX_Store ON dbo.[Store]([ParentStoreId], [Type], [Phone])
并在应用程序服务器上对这两个列表进行排序,您可以在其中合并(如合并排序)预排序的列表,从而避免进行完整的排序。但这实际上是一个微优化,虽然将排序本身加快了一个数量级,却不太可能对查询的总执行时间产生很大影响,因为我希望瓶颈是网络和磁盘I / O,尤其是考虑到由于索引未聚集,磁盘将执行大量随机访问。