nicht angemeldet
Hallo,
zu pauschal, ohne den ausführungsplan zu kennen kann man nicht sagen, ob er indexe braucht oder ob sie alles nur verlangsamen.
wie gesagt: der versuch war, dass ohne pk/index die daten eingetragen wurden und anschließend die 45gb tabelle mit einem pk als kombination von 2 unique int-Feldern auszustatten.
grundsätzlich solltest Du Dir das Handbuchkapitel Optimization vornehmen, falls Du dies noch nicht getan haben solltest. Darin könnten Dich die vorkonfigurierten Option-Files interessieren. Vielleicht hilft Dir my-huge.cnf bzw. my-huge.ini bereits weiter. Out-of-the-box ist MySQL normalerweise nicht für riesige Datenmengen konfiguriert, weil diese in den meisten Fällen nicht vorhanden sind.
Weiterhin sind folgende Abschnitte aus dem Kapitel Optimization besonders interessant:
- Multiple-Column Indexes
- How MySQL Uses Indexes
Wenn Du den Mehrspaltenindex nicht nutzt, dann laß ihn weg. Willst Du nur einen PK um des PKs willen, nutze eine künstliche Spalte. Einziges Interesse bei Deiner Anwendung sind ja Leseoperationen. Du kennst Deine Anwendung, ermittle, ob Dir diese vom Mehrspaltenindex profitieren können. Wenn nein, weg damit. Die typische Frage wird doch eher so sein:
Gib mir die Datensätze, für die die Entfernung zu einem gegebenen Ort geringer ist als eine bestimmte Grenze. Da Du auf die doppelte Speicherung verzichten willst, kann dieser gegebene Ort sowohl in der ersten Spalte als auch in der zweiten Spalte stehen und Deine Abfrage wird somit eine UNION zweier Teilabfragen werden:
Gib mir die Datensätze,
für die die Entfernung zu Ort X
in Spalte A geringer ist als eine bestimmte Grenze.
Vereinigt mit
den Datensätzen,
für die die Entfernung zu Ort X
in Spalte B geringer ist als eine bestimmte Grenze.
Ich sehe daher keine Notwendigkeit für einen kombinierten Index über die beiden Ortsspalten, eher welche für kombinierte Indexe über (Ortsspalte A, Entfernung) und (Ortsspalte B, Entfernung).
Freundliche Grüße
Vinzenz