mysql - SPATIAL Geometry 索引性能是否取决于几何形状的大小和密度？

Question

空间索引

给定一个空间索引，是索引效用，也就是说索引的整体性能，只和整体的几何形状一样好。

例如，如果我要获取一百万个几何数据类型并将它们插入到一个表中，以便它们的相对点彼此密集定位，这是否会使该索引对相对位置可能为稀疏得多。

问题1

例如，采用这两个几何形状。

情况一

LINESTRING(0 0,1 1,2 2)
LINESTRING(1 1,2 2,3 3)

它们在几何上是相同的，但它们的坐标相差一个点。想象一下，这被重复了一百万次。

现在以这种情况为例，

情况2

LINESTRING(0 0,1 1,2 2)
LINESTRING(1000000 1000000,1000001 10000001,1000002 1000002)
LINESTRING(2000000 2000000,2000001 20000001,2000002 2000002)
LINESTRING(3000000 3000000,3000001 30000001,3000002 3000002)

在上面的例子中:

• 线条尺寸与情况1相同，
• 直线的点数相同
• 线条的大小相同。

但是，

• 区别是线条相距很远。

---

为什么这对我很重要？

我问这个问题的原因是因为我想知道我是否应该尽可能多地从我的输入几何图形中删除精度，并在我的应用程序可以提供的情况下尽可能多地降低它们的密度和彼此的接近度而不损失精度。

问题2

这个问题与第一个问题类似，但不是在空间上接近另一个几何形状，而是应该将形状本身缩小到尽可能小的形状以描述应用程序需要的是什么。

例如，如果我要在几何数据类型上使用 SPATIAL 索引来提供日期数据。如果我想存储两个日期的日期范围，我可以在 mysql 中使用日期时间数据类型。但是，如果我想使用几何类型怎么办，以便通过获取每个单独的日期并将其转换为 unix_timestamp() 来转换日期范围。

例如:

 Date("1st January 2011") to Timestamp =  1293861600
 Date("31st January 2011") to Timestamp =  1296453600

现在，我可以根据这两个整数创建一个 LINESTRING。

 LINESTRING(1293861600 0,1296453600 1)

如果我的应用程序实际上只关心天数，而秒数对于日期范围根本不重要，我是否应该重构我的几何图形，以便将它们缩小到尽可能小的尺寸以满足它们的需要.

因此，我将使用“1293861600”/(3600 * 24) 而不是“1293861600”，恰好是“14975.25”。

有人可以帮助填补这些空白吗？

Answer 1

插入新条目时，引擎会选择扩展最少的 MBR。

“最小扩展”，引擎可以表示“区域扩展”或“周边扩展”，前者在 MySQL 中是默认的。

这意味着只要您的节点具有非零面积，它们的绝对大小就无关紧要:较大的 MBR 保持较大，较小的保持较小，最终所有节点都会最终进入相同的 MBR

您可能对这些文章感兴趣:

• Overlapping ranges in MySQL
• Join on overlapping date ranges

至于密度，MBR 在页面拆分时重新计算，所有离主集群太远的点很有可能在第一次拆分时被移到它们自己的位置MBR。它会很大，但在几次迭代后成为所有突出点的父项。

这将减少对突出点的搜索时间，并通过一页搜索增加对聚类点的搜索时间。