空间索引没有任何好处

Question

我有一个大型查询，试图将质心与它们所在的多边形相匹配。虽然我通过块和多边形的Z值进行约束，但它仍然执行很多的多点聚合计算并且需要长时间来运行。

对于某些背景：

• 包含质心的表格有2.5M行
• 表格中的所有空间数据都在世界相当小的区域内，整个事物的边界框只有7643 x 2351米
• 在这些行中，660K符合Z critera
• 包含多边形的表格有10K行
• 表中的所有空间数据都位于世界上更小的区域
• 在这些行中，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。

毕竟，这是查询计划：

滤波器成本：

但是，在添加这3个索引后，查询仍然需要运行一段时间 我现在能做什么？

Answer 1

我认为空间索引没有多大帮助的原因可能与地球上这么小区域的数据密度有关。
我已经对此进行了一些实验，最好的选择似乎是指数上尽可能高的密度。

在SQL Server 2008中，这是通过在4个级别的空间索引网格中使用HIGH。 通过暗示优化器使用此索引，我将连接击倒约1小时而不是10！

在SQL Server 2012中，我发现了另外几个有趣的方面：​​
首先，如果其中一个地理对象是一个点，STIntersects（）会更好地优化，就像我的情况一样。在我的机器上，2012年同样的查询运行速度是2008年的两倍。

第二个更令人印象深刻！ 2012年的一种新型空间索引最多可使用8个级别的曲面细分。我猜测密集数据特别适合索引中几何级别更高级别的细分，因为当暗示使用新索引而不是旧的4级时，同一查询运行速度快45倍。