1

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

对于一些背景：

  • 包含质心的表有 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。

毕竟，这是查询计划：
SSMS 查询计划

和过滤器成本：
SSMS 过滤器成本

但是，在添加这 3 个索引之后，查询仍然需要同样长的时间才能运行。
我现在能做什么？

4

1 回答 1

0

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

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

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

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

于 2012-05-31T08:17:16.860 回答