空间索引没有任何好处答案

【问题标题】：Spatial Indexes providing no benefit空间索引没有任何好处
【发布时间】：2012-05-29 00:55:11
【问题描述】：

我有一个大型查询，它试图将质心与它们适合的多边形进行匹配。虽然我确实限制了块和多边形的 Z 值，但它仍然会进行很多多点计算，并且需要很长时间来运行。 p>

对于一些背景：

包含质心的表有 250 万行
表中的所有空间数据都在世界上很小的区域，整个事物的边界框只有 7643 x 2351 米
在这些行中，660K 符合 Z 标准
包含多边形的表有 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 个索引后，查询仍然需要同样长的时间才能运行。
我现在能做什么？

【问题讨论】：

@DavidBrabant：索引是新创建的；我怀疑这会有所帮助。
实际上，当我使用 WITH(INDEX(CentroidSpatialIndex)) 尝试提示查询分析器时，我可以看到聚集索引搜索上面有一个 /!\ 图标。我试图运行 CREATE STATISTICS，但我收到错误 Column 'WGS84Centroid' in table 'dbo.blocks' is of an type that is invalid for used as a key column in index or statistics.

标签： sql-server-2008 tsql geospatial spatial-index

【解决方案1】：

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

在 SQL Server 2008 中，这是通过在 4 级空间索引网格的每一级上使用 HIGH。通过提示优化器使用此索引，我将连接降低到 ~1 小时而不是 10 小时！

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

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

【讨论】：