it-swarm-eu.dev

Wie wirken sich lange Spalten auf die Leistung und die Festplattennutzung aus?

In unserem aktuellen Projekt kommt es einfach zu oft vor, dass wir Spalten um einige Zeichen erweitern müssen. Von varchar(20) bis varchar(30) und so weiter.

Wie wichtig ist es in Wirklichkeit wirklich? Wie gut ist das optimiert? Was bewirkt es, wenn nur 100 oder 200 oder sogar 500 Zeichen für normale "Eingabe" -Felder zugelassen werden? Eine E-Mail kann nur 320 Zeichen enthalten, also ok - dort gibt es ein gutes Limit. Aber was bekomme ich, wenn ich es auf 200 setze, weil ich keine längeren E-Mail-Adressen erwarte.

Normalerweise haben unsere Tabellen nicht mehr als 100.000 Zeilen und bis zu 20 oder 30 solcher Spalten.

Wir verwenden jetzt SQL Server 2008, aber es wäre interessant zu wissen, wie verschiedene DBs mit diesen Problemen umgehen.

Falls die Auswirkungen sehr gering sind - wie ich erwarten würde, wäre es hilfreich, einige gute Argumente (mit Links gesichert?) Zu erhalten, um meinen DBA davon zu überzeugen, dass diese Langfeldparanoia nicht wirklich notwendig ist.

Falls es so ist, bin ich hier, um zu lernen :-)

27

Die spezifische Antwort auf Ihre Frage (mindestens für Oracle und wahrscheinlich andere Datenbanken) lautet, dass die Länge des Felds keine Rolle spielt, sondern nur die Länge der Daten. Dies sollte jedoch nicht als entscheidender Faktor dafür verwendet werden, ob das Feld auf seine maximal zulässige Länge eingestellt werden soll oder nicht. Hier sind einige andere Punkte, die Sie berücksichtigen sollten, bevor Sie die Feldgrößen maximieren.

Formatierung Jedes Client-Tool, das die Daten basierend auf der Größe der Felder formatiert, erfordert spezielle Formatierungsüberlegungen. In Oracle * SQL * Plus wird beispielsweise standardmäßig die maximale Größe von Varchar2-Spalten angezeigt, auch wenn die Daten nur ein Zeichen lang sind. Vergleichen Sie…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Fehlerhafte Daten Die Feldlänge bietet einen zusätzlichen Mechanismus zum Abfangen/Verhindern fehlerhafter Daten. Eine Schnittstelle sollte nicht versuchen, 3000 Zeichen in ein Feld mit 100 Zeichen einzufügen. Wenn dieses Feld jedoch als 4000 Zeichen definiert ist, ist dies möglicherweise der Fall. Der Fehler wird bei der Dateneingabe nicht abgefangen, aber das System hat möglicherweise weiter unten Probleme, wenn eine andere Anwendung versucht, die Daten und Drosseln zu verarbeiten. Wenn Sie sich später entscheiden, das Feld in Oracle zu indizieren, überschreiten Sie beispielsweise die maximale Schlüssellänge (abhängig von Blockgröße und Verkettung). Sehen…

create index i1 on f1(a);

Speicher Wenn die Clientanwendung Speicher mit der maximalen Größe zuweist, würde die Anwendung erheblich mehr Speicher zuweisen, als erforderlich ist. Um dies zu vermeiden, müssten besondere Überlegungen angestellt werden.

Dokumentation Die Größe des Feldes bietet einen weiteren Datenpunkt für die Dokumentation der Daten. Wir könnten alle Tabellen t1, t2, t3 usw. und alle Felder f1, f2, f3 usw. aufrufen, aber durch Angabe aussagekräftiger Namen verstehen wir die Daten besser. Wenn eine Adresstabelle für ein Unternehmen mit Kunden in den USA beispielsweise ein Feld mit dem Namen "Status" enthält, das aus zwei Zeichen besteht, wird die Abkürzung für den Status "Zwei Zeichen" voraussichtlich darin enthalten sein. Wenn das Feld jedoch aus hundert Zeichen besteht, können wir erwarten, dass der vollständige Statusname in das Feld eingefügt wird.


Trotzdem erscheint es ratsam, auf Veränderungen vorbereitet zu sein. Nur weil alle Ihre Produktnamen heute in 20 Zeichen passen, heißt das nicht, dass sie es immer tun werden. Gehen Sie nicht über Bord und machen Sie es 1000, sondern lassen Sie Raum für plausible Erweiterungen.

12
Leigh Riffel

Hier ist ein guter Ausgangspunkt für Sie.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Ich habe Ihre ursprüngliche Frage möglicherweise falsch verstanden. Lassen Sie mich sehen, ob ich Ihnen ein paar andere Links als Referenz finden kann.

Hier finden Sie eine gute Referenz zur Auswahl von Datentypen: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Der Wechsel von varchar (20) zu varchar (30) mag etwas klein erscheinen, aber Sie müssen mehr über die Funktionsweise von Datenbankstrukturen wissen, um sich der potenziellen Probleme bewusst zu werden. Wenn Sie beispielsweise zu varchar (30) wechseln, können Sie den Wendepunkt Ihrer Spalten überschreiten (sollten alle 30 Bytes verwendet werden) und auf einer Seite gespeichert werden (weniger als 8060 Bytes). Dies führt zu einer Erhöhung des verwendeten Speicherplatzes, einer Verringerung der Leistung und sogar zu einem zusätzlichen Aufwand für Ihre Transaktionsprotokolle.

Hier ist ein Link für Datenbankstrukturen: http://technet.Microsoft.com/en-us/sqlserver/gg313756.aspx

Hier ist eine für Seitensplits und Trx-Protokollierung: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

9
SQLRockstar

Ich dachte, ich würde einen weiteren interessanten Punkt teilen, den ich in eine Frage zum Stapelüberlauf gefunden habe.

Ursprüngliche Antwort von: Nick Kavadias

Ein Grund, KEINE Max- oder Textfelder zu verwenden, besteht darin, dass Sie auch mit SQL Server Enterprise Edition keine Online-Indexwiederherstellungen durchführen können .

Ich würde dies als großen Nachteil betrachten, wenn n/varchar (max) -Spalten willkürlich hinzugefügt werden, und laut MS Site bleibt diese Einschränkung gegen die Durchführung von Online-Indexwiederherstellungen in SQL Server 2008, 2008 R2 und Denali bestehen. Es ist also nicht spezifisch für SQL Server 2005.

7
Jeff

In einigen Fällen wirkt sich der für ein Varchar-Feld zugewiesene Speicherplatz auf die für In-Memory-Sortierungen zugewiesene Speichermenge aus.

Ich fand die Präsentationen auf SQLWorkshops.com zum Nachdenken anregend. In dieser Präsentation geht es um einen Fall, in dem eine Sortierung für eine Bestellung nach in tempdb übergeht, weil nicht genügend Speicher für char/varchar-Felder zugewiesen wird.

http://webcasts2.sqlworkshops.com/webcasts.asp

Dieser Webcast wurde auch als Artikel auf der folgenden Website präsentiert:

http://www.mssqltips.com/tip.asp?tip=1955

Beachten Sie in dieser Präsentation, dass die zu sortierende Spalte nicht die char/varchar-Spalte ist, aber der für die varchar-Spalte im Speicher zugewiesene Speicherplatz in einigen Fällen einen Unterschied in der Abfrageleistung bewirkt.

6
Jeff

ANSI_PADDING EINSETZEN?

Sie haben am Ende viel Leerzeichen ...

4
gbn

Dies ist nur in Bezug auf Speicherplatz und Zeichenlänge von Bedeutung. Natürlich wirkt die Suche nach char-Datentypen und Indizes für diese Art von Daten langsamer als die Ganzzahl, aber dies ist eine andere Diskussion.

Der Varchar-Datentyp ist ein "variabler" Datentyp. Wenn Sie also eine Grenze von varchar (500) festlegen, ist dies die maximale Zeichenlänge für dieses Feld. Die Mindestlänge kann zwischen 0 und 500 liegen. Andererseits ist der beanspruchte Speicherplatz für Felder mit 10, 30 oder 500 Zeichen unterschiedlich.

Ich habe manchmal einen Test für den Datentyp varchar (800) durchgeführt und für Nullwerte wurden 17 Bytes verwendet, und für jedes eingefügte Zeichen wurde ein weiteres Byte hinzugefügt. Zum Beispiel hatte eine 400-Zeichenfolge 417 Bytes, die auf der Festplatte verwendet wurden.

2
yrushka

Ich glaube nicht, dass es einen Unterschied zwischen Tabellen gibt, die mit Spalten von varchar (20) oder varchar ((8000) erstellt wurden, solange die tatsächliche maximale Länge <= 20 ist.

Auf der anderen Seite kann es in einigen Fällen hilfreich sein, den Benutzern die Möglichkeit zu geben, längere Zeichenfolgen zu speichern.

2
bernd_k