kleiner Hinweis in dem Zusammenhang übrigens in Bezug auf Performanceunterschiede bei viel/wenig Indizes
Folgende Werte habe ich vor kurzem mal in einer Kundenschulung ermittelt:
Tabelle
Code:
create table test
(id bigint not null primary key,
txt varchar(80))
Variante 1: auf der Spalte TXT wurde genau 1 Index angelegt
Variante 2: auf der Spalte TXT wurden 100 Indizes angelegt
Test Insert von 10000 Datensätzen
Laufzeit Variante 1 mit einem Index auf TXT: 0,35 Sekunden
Laufzeit Variante 2 mit 100 Indizes auf TXT: 12,31 Sekunden
Zu viele Indizes anlegen, die man eigentlich nicht braucht, ist also ein erheblicher Zeitfaktor beim Schreiben.
Vorteile ergeben sich daher bei Firebird für die Variante single column indizes, weil der Optimierer diese
nach Bedarf kombiniert benutzen kann. Für andere Datenbanken gilt diese Regel aber eben nicht, weil die meisten
eben keine Indizes kombiniert benutzen können.
Ich sehe auch immer wieder Datenbanken beim Kunden, wo gleichartige Indzes mehrfach existieren. Das lässt sich
mit einem
SQL in Firebird über RDB$INDICES und RDB$INDEXSEGMENTS relativ einfach finden. Auch non unique Indizes
auf Feldern, wo eh schon unique indizes existieren, ergeben selten Sinn.
Es ist auch hier wie fast immer: Es kommt drauf an, was man braucht und wie die eigene Umgebung damit umgeht.
Ach ja, und ergänzend: Bei Tabellen mit 200 Mio Datensätzen oder noch mehr würde ich auch versuchen, kombinierte
Indizes gemäß der
SQL Anforderungen bereitzustellen, weil bei wirklich großen Datenmengen (meiner Meinung nach
ab 10 mio Datensätze) die Kombination von Single Column Indizes nicht unbedingt den gleichen Speed ergibt.
Wenn die Kombinierten Indizes aber nicht passen oder halt was fehlt, wie hier bei der ursprünglichen Kundentabelle,
dann sollte man eben ggf. die verschlechterte Schreibleistung in Kauf nehmen, weil am Ende der Server weniger
Last durch unsinnige Lesevorgänge hat und über alles betrachtet fast immer trotzdem bessere Performance haben wird.
Testgrundlage war hier wieder Firebird 2.5.4