2010-07-19 12 views
7

Für Sie Datenbank Design/Performance-Gurus da draußen.Sql Server Int vs Nvarchar Vergleich der Leistung?

Ich entwerfe eine Tabelle, ich habe die Wahl, entweder int oder nvarchar (128) für eine Spalte verwenden, Raum ist kein Problem. Meine Frage ist, welche Leistung

geben wird, wenn ich mit int Spalte suchen

where ID = 12324

oder wenn ich mit nvarchar Spalte zu suchen (der Schlüssel ist der gesamte Wert, so dass ich bin nicht mit LIKE-Operator)

where Key = 'my str'

ich bin für kleinere Datenmengen sicher, dass es keine Rolle spielt, aber wir werden diese Daten in den Millionen von Zeilen sein nehmen wird.

Antwort

17

INT wird schneller sein - hier ist der Grund:

  • SQL Server seine Daten und Index in Seiten von 8K
  • organisiert, wenn Sie eine Indexseite mit INT-Taste auf sie haben, erhalten Sie etwa 2'000 INT Einträge
  • wenn Sie NVARCHAR (128) und Sie verwenden im Durchschnitt 20 Zeichen, das ist 40 Bytes pro Eintrag oder rund 200 Einträge pro Seite

Also für die gleiche Menge an Indexeinträge, die NVARCHAR (128) ca Se würde zehnmal so viele Indexseiten verwenden.

Das Laden und Durchsuchen dieser Indexseiten wird erheblich mehr E/A-Vorgänge erfordern.

Um die Sache kurz zu machen: Wenn du kannst, benutze immer INT.

5

Das Hauptproblem mit der Leistung mit diesem ist die Größe des Feldes - ein int ist 4 Bytes, während ein nvarchar(128) wird 254 Bytes.

All dies muss von SQL-Server verwaltet werden, so dass die Verwaltung einer int wird viel schneller als eine nvarchar(128).

+1

+1 guten Punkt. Außerdem gibt es ein bisschen weniger Arbeit, um eine CPU dazu zu bringen, einen int anstatt einer Zeichenkette zu verarbeiten. Bei Millionen von Zeilen könnte dies zu einem nicht zu vernachlässigenden Unterschied führen. Ich wäre daran interessiert, einige echte Leistungstests zu diesem Thema zu sehen. –

8

Speicherplatz 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. Also ein Schlüssel vom Typ nvarchar(128) wird fast immer schlimmer sein als ein INT.

Auf der anderen Seite, verwenden Sie keine INT-Taste, wenn nicht geeignet ist. Verwenden Sie immer den entsprechenden Schlüssel unter Berücksichtigung Ihrer Abfragen. Wenn Sie immer nach einem nvarchar (128) -Spaltenwert abfragen, dann ist möglicherweise ein guter geclusterter Schlüsselkandidat. Wenn Sie aggregieren durch den Nvarchar (128) Schlüssel gehen, dann ist wahrscheinlich ein guter geclusterter Schlüsselkandidat.

+2

+1: Natürliche> künstliche Schlüssel, aber es gibt sehr wenige natürliche Schlüssel IME. –

0

Ich würde den Int für die Leistung verwenden (wenn dies Joins speziell hat) und einen eindeutigen Index auf den möglichen natürlichen Schlüssel für die Datenintegrität setzen.