6

背景

我有一个表，其中包含代表客户区域的 POLYGONS/MULTIPOLYGONS：

  • 该表包含大约 8,000 行
  • 大约 90% 的多边形是圆形
  • 其余的多边形代表一个或多个州、省或其他地理区域。这些形状的原始多边形数据是从美国人口普查数据中导入的。
  • 该表在主键上有一个空间索引和一个聚集索引。未对默认 SQL Server 2008 R2 设置进行任何更改。每个对象 16 个单元格，所有级别中等。

这是一个简化的查询，它将重现我遇到的问题：

DECLARE @point GEOGRAPHY = GEOGRAPHY::STGeomFromText('POINT (-76.992188 39.639538)', 4326)

SELECT terr_offc_id
FROM tbl_office_territories
WHERE terr_territory.STIntersects(@point) = 1

看似简单、直接的查询需要 12 或 13 秒才能执行，并且对于这样一个简单的查询，执行计划似乎非常复杂。

执行计划

在我的研究中，一些消息来源建议在查询中添加索引提示，以确保查询优化器正确使用空间索引。添加WITH(INDEX(idx_terr_territory))没有任何效果，从执行计划中可以清楚地看出，无论提示如何，它都在引用我的索引。

减少多边形

从美国人口普查数据导入的领土多边形似乎过于复杂，因此我创建了第二列，并测试了具有不同程度公差的缩减多边形（使用Reduce() 方法）。对新列运行与上述相同的查询会产生以下结果：

  • 不减少：12649ms
  • 减少10：7194ms
  • 减少20：6077ms
  • 减少 30：4793ms
  • 减少 40：4397ms
  • 减少50：4290ms

显然朝着正确的方向前进，但降低精度似乎是一个不雅的解决方案。这不是索引应该用于的吗？对于这样一个基本查询，执行计划似乎仍然异常复杂。

空间索引

出于好奇，我去掉了空间索引，结果惊呆了：

  1. 在没有索引的情况下查询更快（低于 3 秒，不减少，低于 1 秒，减少容差 >= 30）
  2. 执行计划看起来要简单得多：

不带索引的执行计划

我的问题

  1. 为什么我的空间索引会减慢速度？
  2. 为了加快查询速度，真的有必要降低我的多边形复杂性吗？降低精度可能会导致问题出现，并且似乎不会很好地扩展。

其他注意事项

  • 已应用 SQL Server 2008 R2 Service Pack 1
  • 进一步的研究建议在存储过程中运行查询。试过这个，似乎没有任何改变。
4

2 回答 2

1

我的第一个想法是检查索引的边界坐标；看看它们是否涵盖了您的整个几何图形。其次，根据我的经验，默认 16MMMM 的空间索引性能很差。我不确定为什么这是默认设置。我在这个答案上写了一些关于空间索引调整的东西。

首先确保索引涵盖所有几何图形。然后尝试将每个对象的单元格减少到 8 个。如果这两件事都没有提供任何改进，那么在我上面链接的答案中运行空间索引调整过程可能是值得的。

最后的想法是，州边界有很多顶点，并且有很多州边界多边形，您正在测试它们是否相交，很可能需要很长时间而不减少它们。

哦，既然已经两年了，从 SQL Server 2012 开始，现在有一个GEOMETRY_AUTO_GRID tessellation可以为您进行索引调整并且大部分时间都做得很好。

于 2014-06-26T18:14:42.037 回答
0

这可能只是由于并行执行更简单的执行计划，而另一个不是。但是，第一个执行计划有一个警告，可能值得调查。

于 2013-01-13T21:44:31.223 回答