Wat je ziet, is helaas een algemeen probleem met de manier waarop ruimtelijke functies worden geïmplementeerd in MySQL en een gerelateerde zwakte met subquery's met ruimtelijke functies.
Om de functies Bevat en Snijpunten goed te laten werken, en om de index te gebruiken, moet een van de geometrieën een constante zijn. Dit lijkt niet te zijn gedocumenteerd, hoewel alle voorbeelden die u zult zien met MySQL met Intersects/Contains op deze manier werken.
Je kunt dus niet zoiets schrijven, zoals je zou kunnen in Oracle Spatial of Postgis,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
Als in een dergelijke zoekopdracht tabellen a en b beide ruimtelijke indexen hebben, worden deze gebruikt, op voorwaarde dat dit meer beperkend is dan een ander attribuut dat u in de where-clausule zou kunnen plaatsen.
Hetzelfde geldt voor self-joins, waarbij u alle polygonen wilt vinden die alle andere polygonen kruisen in een tabel op basis van een attribuut, bijv.
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Dus in MySQL-ruimtelijk ben je gedwongen om een van de geometrieën een constante te hebben.
Even terzijde, de syntaxis van de linker join heeft niet veel zin met ruimtelijk (hoewel het wordt ondersteund), omdat je niet echt samenvoegt op een enkel overeenkomend attribuut, maar op een 2-dimensionale insluiting / intersectie-operator.
Ik ben er ook vrij zeker van dat op je inner join de index niet wordt gebruikt, als je kijkt naar de key en rows uitvoer van uitleggen.