Det du ser är, tyvärr, ett allmänt problem med hur rumsliga funktioner implementeras i MySQL och en relaterad svaghet med underfrågor som involverar rumsliga funktioner.
För att funktionerna Contains och Intersects ska fungera korrekt, och för att indexet ska användas, måste en av geometrierna vara en konstant. Detta verkar inte vara dokumenterat, även om alla exempel du kommer att se med MySQL med Intersects/Contains fungerar på detta sätt.
Så du kan inte skriva något sånt här, som du kan i Oracle Spatial eller Postgis,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
I en sådan fråga, om tabellerna a och b båda har rumsliga index, kommer de att användas, förutsatt att detta är mer restriktivt än något annat attribut du kan lägga i where-satsen.
Detsamma gäller för självkopplingar, där du vill hitta alla polygoner som skär alla andra polygoner i en tabell baserat på något attribut, t.ex.
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Så i MySQL spatial är du tvungen att ha en av geometrierna en konstant.
Till skillnad från det är syntaxen för vänster koppling inte särskilt meningsfull med rumslig (även om den stöds), eftersom du egentligen inte går med på ett enda matchat attribut, utan på en 2-dimensionell inneslutnings-/korsningsoperator.
Dessutom är jag ganska säker på att indexet inte används på din inre koppling, om du tittar på key och rows output av förklara.