Was Sie sehen, ist leider ein allgemeines Problem mit der Art und Weise, wie räumliche Funktionen in MySQL implementiert sind, und eine damit verbundene Schwäche bei Unterabfragen, die räumliche Funktionen beinhalten.
Damit die Funktionen Contains und Intersects ordnungsgemäß funktionieren und der Index verwendet werden kann, muss eine der Geometrien eine Konstante sein. Dies scheint nicht dokumentiert zu sein, obwohl alle Beispiele, die Sie mit MySQL mit Intersects/Contains sehen werden, auf diese Weise funktionieren.
Sie können also so etwas nicht schreiben, wie Sie es in Oracle Spatial oder Postgis könnten,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
Wenn in einer solchen Abfrage die Tabellen a und b beide räumliche Indizes haben, werden sie verwendet, vorausgesetzt, dies ist restriktiver als ein anderes Attribut, das Sie möglicherweise in die where-Klausel einfügen.
Dasselbe gilt für Selbstverknüpfungen, bei denen Sie alle Polygone finden möchten, die sich mit allen anderen Polygonen in einer Tabelle schneiden, basierend auf einem Attribut, z. B.
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
In MySQL Spatial muss also eine der Geometrien eine Konstante sein.
Abgesehen davon macht die Left-Join-Syntax mit Spatial (obwohl sie unterstützt wird) nicht viel Sinn, da Sie nicht wirklich an einem einzelnen übereinstimmenden Attribut teilnehmen, sondern an einem zweidimensionalen Containment/Intersection-Operator.
Außerdem bin ich mir ziemlich sicher, dass bei Ihrem inneren Join der Index nicht verwendet wird, wenn Sie sich den key ansehen und rows Ausgabe von Erklären.
