空间几何索引的性能是否取决于几何形状的大小和密度？

Question

空间索引

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

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

问题 1

例如，取这两个几何形状。

情况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

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

例如，如果我要对几何数据类型使用空间索引来提供日期数据。 如果我想存储两个日期的日期范围，我可以在 mysql 中使用 datetime 数据类型。但是，如果我想使用几何类型怎么办，以便通过获取每个单独的日期并将其转换为 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 保持较大，较小的保持较小，最终所有节点都将在同一个MBRs

您可能会对这些文章感兴趣：

• Overlapping ranges in MySQL
• Join on overlapping date ranges

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

这将减少未完成点的搜索时间，并将聚类点的搜索时间增加一页搜索。