Det, du ser, er desværre et generelt problem med den måde, rumlige funktioner implementeres i MySQL og en relateret svaghed med underforespørgsler, der involverer rumlige funktioner.
For at funktionerne Indeholder og Skærer skal fungere korrekt, og for at indekset kan bruges, skal en af geometrierne være en konstant. Dette ser ikke ud til at være dokumenteret, selvom alle de eksempler, du vil se med MySQL med Intersects/Contains, fungerer på denne måde.
Så du kan ikke skrive sådan noget, som du kunne 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 forespørgsel, hvis tabellerne a og b begge har rumlige indekser, vil de blive brugt, forudsat at dette er mere restriktivt end en anden egenskab, du kan sætte i where-sætningen.
Det samme gælder for selvbindinger, hvor du vil finde alle polygoner, der skærer alle andre polygoner i en tabel baseret på en eller anden egenskab, f.eks.
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Så i MySQL spatial er du tvunget til at have en af geometrierne en konstant.
Som en sidebemærkning giver den venstre join-syntaks ikke meget mening med rumlig (selvom den understøttes), da du ikke rigtig joiner på en enkelt matchet attribut, men på en 2-dimensionel indeslutnings-/krydsningsoperator.
Jeg er også ret sikker på, at indekset på dit indre led ikke bliver brugt, hvis du ser på key og rows output af forklar.