1
我有一個查詢嘗試查找某個邊界框[地理編碼查找]中的所有記錄。爲什麼我的查詢執行聚集索引掃描
通過RedGate探查器運行查詢計劃後，它在聚集索引掃描（下面）中花費了大量時間（問題底部的有問題的查詢）。這是我運行速度最慢的查詢，我猜這有什麼問題，因爲最後一步花了這麼長時間？
有後環顧四周SO和谷歌，我決定，包括我的索引中的表的所有列。這裏是我有什麼指數
- PK上的Id。在[UTC_UPDATED說明，北，東，南，西]
- 指數[包括所有其他列儘量避免掃描]對[UTC_UPDATED說明，來源說明]
- 指數
查詢：
SET ANSI_NULLS ON; SET ANSI_PADDING ON; SET ANSI_WARNINGS ON; SET ARITHABORT OFF; SET CONCAT_NULL_YIELDS_NULL ON; SET NUMERIC_ROUNDABORT OFF; SET QUOTED_IDENTIFIER ON
(@p__linq__0 datetime2(7),@p__linq__1 float,@p__linq__2 float,@p__linq__3 float,@p__linq__4 float)SELECT
[Project1].[ID] AS [ID],
[Project1].[CENTER] AS [CENTER],
[Project1].[BOUNDS] AS [BOUNDS],
[Project1].[UTC_UPDATED] AS [UTC_UPDATED],
[Project1].[PLACE_ID] AS [PLACE_ID],
[Project1].[FORMATTED_ADDRESS] AS [FORMATTED_ADDRESS],
[Project1].[POST_CODE] AS [POST_CODE],
[Project1].[SOURCE] AS [SOURCE],
[Project1].[North] AS [North],
[Project1].[East] AS [East],
[Project1].[South] AS [South],
[Project1].[West] AS [West]
FROM (SELECT
[Extent1].[ID] AS [ID],
[Extent1].[CENTER] AS [CENTER],
[Extent1].[BOUNDS] AS [BOUNDS],
[Extent1].[UTC_UPDATED] AS [UTC_UPDATED],
[Extent1].[PLACE_ID] AS [PLACE_ID],
[Extent1].[FORMATTED_ADDRESS] AS [FORMATTED_ADDRESS],
[Extent1].[POST_CODE] AS [POST_CODE],
[Extent1].[SOURCE] AS [SOURCE],
[Extent1].[North] AS [North],
[Extent1].[East] AS [East],
[Extent1].[South] AS [South],
[Extent1].[West] AS [West]
FROM [dbo].[HST_GEOCODE_POINTS] AS [Extent1]
WHERE ([Extent1].[UTC_UPDATED] > @p__linq__0)
AND ([Extent1].[North] >= @p__linq__1)
AND ([Extent1].[East] >= @p__linq__2)
AND ([Extent1].[South] <= @p__linq__3)
AND ([Extent1].[West] <= @p__linq__4)
) AS [Project1]
ORDER BY [Project1].[UTC_UPDATED] DESC, [Project1].[SOURCE] DESC
注邊界和中心是地理類型。我最初使用Intersects來查找正確的Geocoded地址，但它非常慢，我選擇使用SQL [它們只是雙倍]來找到粗糙的NESW邊界框，然後在代碼[.NET]中相交。
在決定放棄SQL Server地理支持之前，您是否考慮/測試空間索引？鑑於大多數搜索謂詞都是不等式，非聚集索引實際上是無用的。 –
從小處着手，重點關注您的搜索謂詞（where子句）並返回您在內部Project 1表中過濾的列之一。確認它使用您的非聚集索引。添加額外的列可能會混淆優化器。 – user3112728
沒有可以使用的索引。您的索引的前導列是UTC，並且在查詢中沒有UTC的條件。集羣索引掃描是唯一可行的方法。 – sepupic