Question

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

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

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

现在，我正在尝试利用SQL 2008的空间功能。我创建了Geography列，填充它，创建空间索引，工作。

这一切都运行正常，除了执行计划有一百万步，并且74％的时间花在了Clustered Index Seek上，它将它在Spatial Index中找到的行连接到实际表，到得到剩下的数据......
（空间索引搜索占执行计划成本的1％）

所以，显然，它恰当地使用了空间索引并且使用我的“常规”索引比Lat / Long更快地找到我需要的记录，但加入主表是杀了我，空间查询需要是我原来的7倍。

有没有办法在空间索引中添加更多列，以便它可以覆盖它，它可以一步完成，就像以前一样？还有其他方法可以改善这种情况吗？

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

谢谢！
丹尼尔

Answer 1

不，遗憾的是，目前无法创建覆盖空间索引 - 查询将始终对基表执行书签查找，以获取行的地理值。

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

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