7

我目前有一个站点，其中包含一个包含 Lat/Long 浮点列的表，以及这 2 列以及我需要检索的另一列的索引。

我一直在查询这个表以获取从某个点开始落在一个半径内的行（我实际上是为了速度而得到一个正方形），但我只需要已经索引的字段，所以这个索引实际上是覆盖，而执行计划只有两个步骤：

Index Seek  (cost: 100%) and SELECT (cost: 0%)

现在，我正在尝试利用 SQL 2008 的空间特性。我已经创建了 Geography 列，填充了它，创建了空间索引，工作正常。

一切正常，除了执行计划有一百万个步骤，74% 的时间花在聚集索引搜索上，它将在空间索引中找到的行连接到实际表中，以获取其余的数据...
（空间索引搜索占执行计划成本的 1%）

因此，显然，它正在适当地使用空间索引，并且通过 Lat/Long 上的“常规”索引比以前更快地找到我需要的记录，但是加入主表是在杀死我，空间查询需要 7 倍只要是我的旧的。

有没有办法向空间索引添加更多列，以便它可以覆盖并且可以一步完成，就像以前一样？
我还能做些什么来改善这种情况吗？

更新：我发现“常规”索引可以使用 INCLUDE 关键字“包含”其他列（我不知道，我曾经只是将列包含在索引本身中）
根据此处的文档，该子句不是空间索引的一个选项......有什么想法吗？

谢谢！
丹尼尔

4

1 回答 1

4

不，不幸的是，目前没有办法创建覆盖空间索引 - 查询将始终对基表进行书签查找，以获取该行的地理值。

对于 STIntersects，这显然总是需要的，因为我们仍然需要对实际的地理对象执行二次过滤，以验证它实际上与参数对象相交。但是，如果您不需要确切的答案并且可以使用 Filter()，则可以从索引中提供主键列，而根本不查找基表。支持这一点是我们正在考虑的下一个版本。

在加快当前查询的速度方面，您是否尝试过使用 Filter() 并使用 sp_help_geography_index 的输出调整索引？

于 2010-02-23T01:37:43.357 回答