Solo una nota rápida porque este tipo de cosas se ven una y otra vez:El JOIN en prism_worlds no es necesario porque (lo más probable) no necesita los datos de esa tabla. Básicamente, le está pidiendo a la base de datos "dame todos los nombres de los mundos para los que el nombre es igual a 'algo'". Utilice una subconsulta escalar en su lugar.
Crea un índice único en prism_worlds.world y ejecuta la consulta como
SELECT *
FROM prism_data
WHERE prism_data.world_id = (SELECT w.world_id FROM prism_worlds AS w WHERE w.world = 'DeuxTiersMondes')
LIMIT 1000;
El optimizador descubrirá que prism_data.world_id está restringida a un único valor constante. MySQL ejecutará una consulta con anticipación para determinar este valor y usarlo a lo largo de la consulta. Ver EXPLAIN para la const -subconsulta ejecutada.
Con respecto a prism_data.x , .y y .z :Es posible que desee crear una columna de geometría y un índice espacial para eso. Si necesita ceñirse a valores separados, es posible que desee separar toda la geometría del mundo en vóxeles de tamaño fijo (representados por un solo int) y usar geometría simple para averiguar qué posición cae en qué vóxel.
Mi solución personal sería no pensar demasiado en agregar miles de millones de consultas en esta tabla. Los índices lo harán lento y grande. Use un trabajo cron para llenar una tabla de informes (vista materializada) para producir los resultados antes de tiempo y utilícelos siempre que el trabajo cron aparezca y los actualice nuevamente.
