sql server空间索引性能

我有一张桌子，上面有大约200万条记录。我使用边界框以外的默认值创建一个空间索引。我一直注意到，有些查询非常快，有些则非常慢。确定因素出现在查询中使用的多边形的大小。

在较大的搜索区域，使用WITH(INDEX(SIX_FT5))会大大降低查询速度（从0秒降低到15+秒）。在较小的搜索区域中，情况恰恰相反。

这是我正在测试的一些查询：

快速：

SELECT TOP(1000) * FROM [FT5] WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

慢：

SELECT TOP(1000) * FROM [FT5] WITH(INDEX(SIX_FT5)) WHERE (shape.STIntersects(geometry::STGeomFromText('POLYGON ((-133462.805381701 -668610.241000959, 2934415.68824241 -668610.241000959, 2934415.68824241 2200521.65831815, -133462.805381701 2200521.65831815, -133462.805381701 -668610.241000959))', 2264)) = 1)

有人知道这是怎么回事吗？

sql-server performance spatial-index

— mdm20
source

几天前，我只是在经历类似dba.stackexchange.com/questions/61289/…的问题……我不是从文本生成多边形，而是将点和多边形相交...我指定使用空间索引在这一点上，它具有很好的速度结果。然后，我尝试在多边形上使用空间索引，但效果却很差……这似乎与您的问题完全相反！

— DPSSpatial 2014年

如果你想想看，改变搜索信封的尺寸应该对查询显著的影响-这是通过索引返回的多个行，响应越慢。在某个时候，它变得更快，可以进行全表扫描并根据信封丢弃行。我建议您花更多的时间在空间索引选项上，因为您可能还有优化索引的空间。

— 文斯

您的记录代表点吗？没有说明。另外，您可以发布您使用的创建索引语法吗？是AutoGrid吗？

— gischimp

我使用了“地理自动网格”和“每个对象的像元” =4000。相交了110+百万个点，含〜45K多边形。

— 迈克尔（Michael）

您还必须记住的另一件事是，相交是一个复杂的操作，首先它必须查看绑定的元素是否相交，通过索引进行相对快速的操作，但是对于匹配的每个项目，它必须计算每个项目是否实际上相交，这这是又一个更昂贵的操作，随着多边形更加复杂和/或数量众多，操作也会变得更加昂贵。

— AKK2

如@Vince所评论：

如果您考虑一下，更改搜索信封的大小将对查询产生重大影响-通过索引返回的行越多，响应速度就越慢。在某个时候，它变得更快，可以进行全表扫描并根据信封丢弃行。我建议您花更多的时间在空间索引选项上，因为您可能还有优化索引的空间。

— PolyGeo
source