空間索引不提供任何好處

我有一個大型查詢，試圖將質心與它們內部適合的多邊形進行匹配。雖然我通過塊和多邊形的Z值進行約束，但它仍然會執行點中多邊計算，並且需要運行一段時間才能運行。空間索引不提供任何好處

對於一些背景：

包含質心的表在錶行2.5M
所有空間數據是在世界上相當多的小區域，對邊界框整個事情是隻有7643 X2351米
那些行，660K適合比賽在Z性判據
包含多邊形表有10K行
所有的表空間的數據是在EV連接世界
這些行的小面積，2366人姓名相符的標準
沒有任何索引運行查詢時間爲11小時，返回91K匹配

查詢是這樣的：

select blocks.Id, blocks.WGS84Centroid, polygons.Shape 
from 
blocks inner join polygons 
    on 
    blocks.ZCentre >= (polygons.ZCentre - (polygons.ZLength/2)) and blocks.ZCentre <= (polygons.ZCentre + (polygons.ZLength/2)) and 
    polygons.Shape.STIntersects(blocks.WGS84Centroid) = 1 
inner join name 
    on 
    polygons.nameId = name.ID 
where name.Name = 'blah'

因此，爲了加快此查詢，我在blocks.WGS84Centroid上添加了空間索引，並在polygons.Shape上添加了一個空間索引。
查詢分析器還建議blocks.ZCentre上包含blocks.Id和blocks.WGS84Centroid的非聚簇索引。

畢竟是，這裏的查詢計劃：
SSMS query plan

和過濾成本：
SSMS filter cost

然而，增加的3個指標後，查詢仍然需要同樣長的運行。
我現在可以做什麼？

來源

2012-05-29 Coxy

你更新統計數據？ –

@DavidBrabant：索引是新創建的;我懷疑這會有所幫助。 – Coxy

實際上，當我使用WITH（INDEX（CentroidSpatialIndex））嘗試提示查詢分析器時，我可以看到聚集索引seek在其上有一個/！\圖標。我試圖運行CREATE STATISTICS，但是我得到錯誤表'dbo.blocks'中的列'WGS84Centroid'是一種無效的索引或統計中的鍵列。 – Coxy

我認爲空間指數沒有多大幫助的原因可能與地球上這樣一個小地區的數據密度有關。
我已經嘗試了一下，最好的選擇似乎是儘可能高的索引密度。

在SQL Server 2008中，這是通過在空間索引網格的4個級別中的每一級上使用HIGH來實現的。通過暗示優化器使用這個索引，我將連接減少到1個小時而不是10個！

在SQL Server 2012中，我發現了另外幾個有趣的方面：
第一個是如果其中一個地理對象是點，STIntersects（）會更好地優化，就像我的情況一樣。在我的機器上，相同的查詢在2012年的運行速度是2008年的兩倍。

第二個更令人印象深刻！ 2012年的一種新型空間索引使用多達8層鑲嵌。我猜測密集數據特別適合索引中幾何級別更高的鑲嵌細分，因爲當使用新索引而不是舊4級索引時，相同查詢的運行速度快45倍。

來源

2012-05-31 08:17:16 Coxy

空間索引不提供任何好處

回答

相關問題