Desafortunadamente, lo que está viendo es un problema general con la forma en que se implementan las funciones espaciales en MySQL y una debilidad relacionada con las subconsultas que involucran funciones espaciales.
Para que las funciones Contiene e Interseca funcionen correctamente y para que se utilice el índice, debe tener una de las geometrías constante. Esto no parece estar documentado, aunque todos los ejemplos que verá con MySQL con Intersects/Contains funcionan de esta manera.
Entonces, no puede escribir algo como esto, como podría hacerlo en Oracle Spatial o Postgis,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
En una consulta de este tipo, si las tablas a y b tienen índices espaciales, se utilizarán, siempre que sea más restrictivo que cualquier otro atributo que pueda poner en la cláusula where.
Lo mismo se aplica a las uniones automáticas, donde desea encontrar todos los polígonos que se cruzan con todos los demás polígonos en una tabla en función de algún atributo, por ejemplo,
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Por lo tanto, en MySQL espacial está obligado a que una de las geometrías sea una constante.
Aparte, la sintaxis de combinación izquierda no tiene mucho sentido con espacial (aunque es compatible), ya que en realidad no se está uniendo en un solo atributo coincidente, sino en un operador bidimensional de contención/intersección.
Además, estoy bastante seguro de que en su unión interna el índice no se está utilizando, si observa la key y rows salida de explicación.
