Für Ihre Datenbankdesign / Performance-Gurus da draußen.
Ich entwerfe eine Tabelle, ich habe die Wahl, entweder int oder nvarchar (128) für eine Spalte zu verwenden, nehme an, dass Platz kein Problem ist. Meine Frage ist, welche Leistung geben wird
wenn ich mit der int-Spalte
suche where ID = 12324
oder wenn ich mit der nvarchar-Spalte suche (der Schlüssel ist der gesamte Wert, also verwende ich nicht den LIKE-Operator)
where Key = 'my str'
Ich bin mir sicher, dass es für kleinere Datensätze keine Rolle spielt, aber nehmen wir an, dass diese Daten in Millionen von Zeilen vorkommen.
INT wird schneller sein - hier ist der Grund:
Für die gleiche Anzahl von Indexeinträgen würde der Fall NVARCHAR (128) zehnmal so viele Indexseiten verwenden.
Das Laden und Durchsuchen dieser Indexseiten wird erheblich mehr E / A-Vorgänge erfordern.
Um die Dinge kurz zu machen: Wenn du kannst, benutze immer INT.
Leerzeichen ist immer ein Problem in Datenbanken. Breitere Schlüssel bedeuten weniger Einträge pro Seite, mehr gescannte Seiten, um Werte zu aggregieren und zu summieren, bedeutet mehr IO, weniger Leistung. Bei Clustered-Indizes wird dieses Problem mit jedem nicht gruppierten Index multipliziert, da sie den Suchschlüssel (Clusterschlüssel) in ihren Blättern reproduzieren müssen. Daher ist ein Schlüssel vom Typ nvarchar(128) immer fast immer schlechter als ein INT.
Verwenden Sie andererseits keine INT-Taste, wenn dies nicht angemessen ist. Verwenden Sie immer den entsprechenden Schlüssel, unter Berücksichtigung Ihrer Abfragen . Wenn Sie immer nach einem nvarchar (128) -Spaltenwert abfragen, ist möglicherweise ein guter geclusterter Schlüsselkandidat. Wenn Sie aggregieren mit dem nvarchar (128) -Schlüssel, dann ist wahrscheinlich ein guter geclusterter Schlüsselkandidat.
Tags und Links sql-server performance database-design