我想使用 SDO_JOIN-Operator 来 selfJoin 一个表。
该表具有以下结构：
ID VARCHAR2(20)
形状 SDO_GEOMETRY()
该表有 25778 行。
以下 SDO_JOIN-Statement 需要 90 秒：
SELECT w.id as id1, w2.id as id2
FROM TABLE(SDO_JOIN('nodesWays', 'SHAPE', 'nodesWays', 'SHAPE', 'mask=ANYINTERACT')) c,
nodesWays w, nodesWays w2
WHERE c.rowid1 = w.rowid AND c.rowid2 = w2.rowid;
90 秒是正常时间还是太高了。我不知道什么是执行的好时机。
再见，安德烈
【问题讨论】：
标签： oracle join spatial geography oracle-spatial
SDO_JOIN 旨在将许多空间对象与许多其他对象进行匹配：它是一种“批量”操作，因此需要时间，而且您需要匹配的对象越多，显然需要的时间就越长。它需要多长时间显然也取决于您运行它的硬件类型。 CPU 容量是关键。
关于您的查询，首先删除 SDO_GEOM.RELATE 调用。这是不必要的，因为它已经由主 SDO_JOIN 查询完成。我也认为没有理由使用这些提示。所以试试这个：
SELECT w.id as id1, w2.id as id2
FROM TABLE(SDO_JOIN('nodesWays', 'SHAPE', 'nodesWays', 'SHAPE', 'mask=ANYINTERACT')) c,
nodesWays w, nodesWays w2
WHERE c.rowid1 = w.rowid
AND c.rowid2 = w2.rowid
and c.rowid1 < c.rowid2;
这需要多长时间？
90 秒是个好时间吗？ 50秒是个好时机吗？一根绳子有多长？
真正的问题是：90 秒还是 50 秒适合您的应用程序工作流程？是否满足您的业务需求？如果是这样，你就准备好了。如果您希望更快地获得结果，请尝试在 CPU 能力更强（即处理器速度更快）的系统上运行它。
请注意，SDO_JOIN 目前不利用多核/多 CPU 服务器提供的并行性。您仍然可以使用并行性，但这需要重写查询并使语法更加复杂。然后再问自己一个问题：是否值得努力更快地获得响应？
【讨论】：
鉴于您发布的解释计划，我怀疑您可能很难让它运行得更快，除非您在更好的硬件和更快的 CPU 上运行。请注意，在 SPATIAL_VECTOR_ACCELERATION=TRUE 的 12c 中，sdo_join 的速度要快得多，因此如果可能，请尝试在该版本上运行...即使只是为了测试它的速度。
【讨论】：