Ce que vous voyez est, malheureusement, un problème général avec la façon dont les fonctions spatiales sont implémentées dans MySQL et une faiblesse connexe avec les sous-requêtes impliquant des fonctions spatiales.
Pour que les fonctions Contient et Intersections fonctionnent correctement, et pour que l'index soit utilisé, vous devez avoir l'une des géométries soit une constante. Cela ne semble pas être documenté, bien que tous les exemples que vous verrez avec MySQL avec Intersects/Contains fonctionnent de cette façon.
Donc, vous ne pouvez pas écrire quelque chose comme ça, comme vous pourriez le faire dans Oracle Spatial ou Postgis,
select a.*, b.*
from sometable a, someothertable b
where ST_Intersects(a.geom, b.geom)
and a.someattribute=... and b.someattribute=...;
Dans une telle requête, si les tables a et b ont toutes deux des index spatiaux, ils seront utilisés, à condition que cela soit plus restrictif que tout autre attribut que vous pourriez mettre dans la clause where.
Il en va de même pour les auto-jointures, où vous souhaitez rechercher tous les polygones qui se croisent avec tous les autres polygones d'une table en fonction d'un attribut, par exemple,
select a.*
from sometable a, sometable b
where ST_Intersects(a.geom, b.geom) ....
Ainsi, dans MySQL spatial, vous êtes obligé d'avoir une des géométries constante.
En passant, la syntaxe de jointure à gauche n'a pas beaucoup de sens avec spatial (bien qu'elle soit prise en charge), car vous ne vous joignez pas vraiment à un seul attribut correspondant, mais à un opérateur de confinement/intersection bidimensionnel.
De plus, je suis à peu près sûr que sur votre jointure interne, l'index n'est pas utilisé, si vous regardez la key et rows sortie de l'explication.
