Nur eine kurze Anmerkung, weil so etwas immer wieder zu sehen ist:Der JOIN auf den prism_worlds wird nicht benötigt, da Sie (höchstwahrscheinlich) die Daten aus dieser Tabelle nicht benötigen. Sie fragen die Datenbank im Grunde:"Geben Sie mir jeden Namen von Welten, für die der Name gleich 'etwas' ist". Verwenden Sie stattdessen eine skalare Unterabfrage.
Erstellen Sie einen eindeutigen Index auf prism_worlds.world und führen Sie die Abfrage wie
SELECT *
FROM prism_data
WHERE prism_data.world_id = (SELECT w.world_id FROM prism_worlds AS w WHERE w.world = 'DeuxTiersMondes')
LIMIT 1000;
Der Optimierer wird diese prism_data.world_id herausfinden ist auf einen einzigen konstanten Wert beschränkt. MySQL führt vorab eine Abfrage durch, um diesen Wert herauszufinden, und verwendet ihn während der gesamten Abfrage. Siehe EXPLAIN für die const -Unterabfrage ausgeführt.
Bezüglich prism_data.x , .y und .z :Vielleicht möchten Sie dafür eine Geometriespalte und einen räumlichen Index erstellen. Wenn Sie sich an separate Werte halten müssen, möchten Sie vielleicht die gesamte Weltgeometrie in Voxel fester Größe (dargestellt durch ein einzelnes int) aufteilen und einfache Geometrie verwenden, um herauszufinden, welche Position in welches Voxel fällt.
Meine persönliche Lösung wäre, nicht zu viel darüber nachzudenken, Millionen von Abfragen zu dieser Tabelle hinzuzufügen. Die Indizes machen es langsam und groß. Verwenden Sie einen Cron-Job, um eine Berichtstabelle (materialisierte Ansicht) zu füllen, um die Ergebnisse im Voraus zu produzieren, und verwenden Sie sie, solange der Cron-Job kommt und sie erneut aktualisiert.
