我现在有使用具有纬度/经度浮动列的表的位点,并在这些2列的索引加上另外一个I需要检索。

我经常查询该表得到掉下来的某一点(我真的开始对速度的平方)半径范围内的行,但我只需要那些已经编制索引的字段,因此该指数是实际上覆盖,并且执行计划仅具有2个步骤:

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

现在,我试图利用SQL 2008年我创建了地理列的空间特征的优势,填补它,创造了空间索引,作品。

和这一切工作正常,除了执行计划有一百万步骤,时间74%是花在一个聚集索引查找,它加入它在空间索引中发现的实际表中的行,要获取数据的休息...点击 (的空间索引查找需要执行计划的成本的1%)

所以,很明显,适当地使用空间索引和查找我需要比以前在纬度/龙快得多与我的“正规”指标的记录,但在加入到主表是我的命,空间查询时间7倍只要我的旧的。

时有什么办法可以添加更多的列到空间索引,这样它会被覆盖,它可以在一步做的事情,就像它之前在做什么?结果 是否有其他的事情,我可以做些什么来改善这种情况呢?


更新:我发现“正规军”指标可以“包括”使用包含关键字的其他列(这我不知道,我以前只是包括指数本身的列)点击 根据文档 rel="noreferrer">,该条款不是空间索引选项... 任何想法?

谢谢!点击 丹尼尔

有帮助吗?

解决方案

没有,遗憾的是目前还没有方法来创建一个覆盖空间索引 - 查询会一直做书签查找到基表,以获得该行的地理价值。

有关STIntersects,这显然是总是需要作为我们仍然需要实际的地理对象上执行的二次过滤器,以验证它实际上相交的参数对象。不过,如果你并不需要确切的答案,可以使用过滤器(),那么这将是能够提供从索引中的主键列没有做查找到基表都没有。支持,这是我们正在考虑的下一个版本的东西。

在加快当前的查询方面,你有没有尝试过使用过滤器(),从sp_help_geography_index输出调整你的指数?

scroll top