Optimaler Clustered Index

[Andreas Weichert]

Hallo Leute,

ich glaube ich haben einen Designfehler gemacht, den ich korrigieren sollte. Schaut mal ob ich das richtig sehe.

Ich brauche für eine Tabelle einen Primärschlüssel ID beruhend auf 2 Fremdschlüssel F1 und F2. Ich setze die Textuell zusammen.

ID = F1 + "-" + F2

Ich hätte aber auch umgekehrt
ID = F2 + "-" + F1 nehmen können. Meine Idee war damals F1 nach vorne zu stellen, da hier "früher" der Match entschieden werden kann. F1 ein ist meißt sehr spezifisch. F2 hingegen ist sehr lang und vorne für viele Datensätze identisch.

Für eine Query zu einem einzelne Datensatz ist da der beste Weg - oder ?

Nun brauche ich aber meißtens viele Datensätze aufeinmal und zwar in der F2-"Metrik" zusammen. Meint ähnliche F2 Schlüssel vorne werden vermehrt zusammen abgerufen.

Da ID ein clustered Index ist, liegen die benötigten Datensätze in der Datei weit auseinander (eben in F1-Reihenfolge). Auch ist das RAM-Caching nicht optimal, da viel Blöcke geladen werden müssen.

Mein Frage: Is für diesen Fall
ID = F2 + "-" + F1
zu nehmen performanter ?

Gruß
Andreas

 

[castorp]

Warum nicht einfach einen Index auf beide Spalten? create index ... on ... (f1, f2)

Die Reihenfolge der beiden Spalten hängt davon ab, welche davon öfter in einer WHERE Bedingung auftaucht.

(Ist auch mal wieder ein schönes Beispiel warum ein Clustered Index als "Default" nicht wirklich überzeugend ist: Unsinnige Defaults: Primärschlüssel als Clusterschlüssel)

 

[ukulele]

Je nach DBMS kann man ja auch zusammengesetzte Primärschlüssel und Fremdschlüssel definieren.

Die Reihenfolge ist für die Indexgröße irrelevant, die Datenmenge ist ja gleich. Ob das wegen der "Blocklogik" performanter oder unperformanter ist, müsste man ja relativ einfach herausfinden können in dem man den Index mal ändert.