Even een korte opmerking, want dit soort dingen worden keer op keer gezien:de JOIN op de prism_worlds is niet nodig omdat je (waarschijnlijk) de gegevens uit die tabel niet nodig hebt. Je vraagt eigenlijk aan de database "geef me elke naam van werelden waarvoor de naam gelijk is aan 'iets'". Gebruik in plaats daarvan een scalaire subquery.
Maak een unieke index op prism_worlds.world en voer de query uit zoals
SELECT *
FROM prism_data
WHERE prism_data.world_id = (SELECT w.world_id FROM prism_worlds AS w WHERE w.world = 'DeuxTiersMondes')
LIMIT 1000;
De optimizer zal uitzoeken dat prism_data.world_id is beperkt tot een enkele constante waarde. MySQL voert van tevoren een query uit om deze waarde te achterhalen en deze tijdens de hele query te gebruiken. Zie EXPLAIN voor de const -subquery uitgevoerd.
Met betrekking tot prism_data.x , .y en .z :Misschien wilt u daarvoor een geometriekolom en een ruimtelijke index maken. Als je je aan afzonderlijke waarden moet houden, wil je misschien de hele wereldgeometrie scheiden in voxels van vaste grootte (weergegeven door een enkele int) en eenvoudige geometrie gebruiken om erachter te komen welke positie in welke voxel valt.
Mijn persoonlijke oplossing zou zijn om niet te veel na te denken over het toevoegen van ontelbare vragen aan deze tabel. De indexen maken het langzaam en groot. Gebruik een cron-taak om een rapportagetabel te vullen (gematerialiseerde weergave) om de resultaten van tevoren te produceren en gebruik ze zolang de cron-taak er is en ze opnieuw bijwerkt.