Gibt es einen Vorteil von Varchar (500) gegenüber Varchar (8000)?

Ich habe dies in MSDN-Foren und hier nachgelesen und bin mir immer noch nicht sicher. Ich denke, das ist richtig: Varchar (max) wird als Textdatentyp gespeichert, was Nachteile hat. Nehmen wir also an, Ihr Feld wird zuverlässig weniger als 8000 Zeichen enthalten. Wie ein BusinessName-Feld in meiner Datenbanktabelle. In Wirklichkeit wird ein Firmenname wahrscheinlich immer unter 500 Zeichen liegen (eine Zahl aus meinem Hut ziehen). Es scheint, als ob viele Varchar-Felder, auf die ich stoße, deutlich unter die Anzahl von 8.000 Zeichen fallen.

Soll ich dieses Feld also zu einem Varchar (500) anstelle von Varchar (8000) machen? Nach meinem Verständnis von SQL gibt es keinen Unterschied zwischen diesen beiden. Um das Leben einfacher zu machen, möchte ich alle meine Varchar-Felder als Varchar (8000) definieren. Hat das irgendwelche Nachteile?

Verwandte: Größe der Varchar-Spalten (ich hatte nicht das Gefühl, dass diese meine Frage beantwortet hat).

Vom Standpunkt der Verarbeitung aus macht es keinen Unterschied, varchar (8000) gegenüber varchar (500) zu verwenden. Es ist eher eine "gute Praxis", eine maximale Länge zu definieren, die ein Feld enthalten soll, und Ihren Varchar auf diese Länge zu bringen. Dies kann zur Unterstützung der Datenvalidierung verwendet werden. Wenn Sie beispielsweise eine staatliche Abkürzung mit 2 Zeichen oder eine Postleitzahl mit 5 oder 9 Zeichen festlegen. Früher war dies eine wichtigere Unterscheidung, wenn Ihre Daten mit anderen Systemen oder Benutzeroberflächen interagierten, bei denen die Feldlänge kritisch war (z. B. ein Mainframe-Flatfile-Dataset), aber heutzutage denke ich, dass dies mehr Gewohnheit als alles andere ist.

Ein Beispiel, bei dem dies einen Unterschied machen kann, besteht darin, dass eine Leistungsoptimierung verhindert werden kann, bei der vermieden wird, dass Tabellen mit After-Triggern Informationen zur Zeilenversionierung hinzugefügt werden.

Dies wird hier von SQL Kiwi behandelt

Die tatsächliche Größe der gespeicherten Daten spielt keine Rolle - es kommt auf die potenzielle Größe an.

In ähnlicher Weise war es bei Verwendung speicheroptimierter Tabellen seit 2016 möglich, LOB-Spalten oder Kombinationen von Spaltenbreiten zu verwenden, die möglicherweise die Eingangsgrenze überschreiten könnten, jedoch mit einer Strafe verbunden sind.

(Max) Spalten werden immer außerhalb der Zeile gespeichert. Wenn für andere Spalten die Datenzeilengröße in der Tabellendefinition 8.060 Byte überschreiten kann, schiebt SQL Server die größten Spalten variabler Länge aus der Zeile. Auch hier hängt es nicht von der Menge der Daten ab, die Sie dort speichern.

Dies kann sich stark negativ auf den Speicherverbrauch und die Leistung auswirken

Ein weiterer Fall, in dem das Überdeklarieren von Spaltenbreiten einen großen Unterschied machen kann, ist, ob die Tabelle jemals mit SSIS verarbeitet wird. Der für Spalten mit variabler Länge (nicht BLOB) zugewiesene Speicher ist für jede Zeile in einem Ausführungsbaum festgelegt und entspricht der angegebenen maximalen Länge der Spalten, was zu einer ineffizienten Verwendung von Speicherpuffern führen kann (Beispiel) . Während der SSIS-Paketentwickler eine kleinere Spaltengröße als die Quelle deklarieren kann, wird diese Analyse am besten im Voraus durchgeführt und dort durchgesetzt.

Zurück in der SQL Server-Engine selbst ist ein ähnlicher Fall, dass SQL Server bei der Berechnung der Speicherzuweisung für Zuweisungen für SORTOperationen davon ausgeht, dass varchar(x)Spalten im Durchschnitt x/2Bytes verbrauchen .

Wenn die meisten Ihrer varcharSpalten voller sind, kann dies dazu führen, dass die sortVorgänge ausgeführt werden tempdb.

In Ihrem Fall, wenn Ihre varcharSpalten als 8000Bytes deklariert sind, aber tatsächlich einen Inhalt haben, der viel geringer ist als der, wird Ihrer Abfrage Speicher zugewiesen, den sie nicht benötigt, was offensichtlich ineffizient ist und zu Wartezeiten auf Speicherzuweisungen führen kann.

Dies wird in Teil 2 von SQL Workshops Webcast 1 behandelt, der hier heruntergeladen werden kann oder siehe unten.

use tempdb;

CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))

INSERT INTO  T 
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values

SELECT id,name500
FROM T
ORDER BY number

SELECT id,name8000
FROM T
ORDER BY number

Abgesehen von Best Practices (Antwort von BBlake)

• Mit DDL erhalten Sie Warnungen zur maximalen Zeilengröße (8060) und zur Indexbreite (900 Byte)
• DML stirbt, wenn Sie diese Grenzwerte überschreiten
• ANSI PADDING ON ist die Standardeinstellung, damit Sie am Ende eine ganze Menge Leerzeichen speichern können

Große Spalten haben einige Nachteile, die etwas weniger offensichtlich sind und Sie möglicherweise etwas später bemerken:

• Alle Spalten, die Sie in einem INDEX verwenden, dürfen 900 Byte nicht überschreiten
• Alle Spalten in einer ORDER BY- Klausel dürfen 8060 Byte nicht überschreiten. Dies ist etwas schwer zu verstehen, da dies nur für einige Spalten gilt. Weitere Informationen finden Sie unter Überschreitung der Zeilengröße in SQL 2008 R2.
• Wenn die Gesamtzeilengröße 8060 Byte überschreitet, wird für diese Zeile ein " Seitenverlust " angezeigt. Dies kann sich auf die Leistung auswirken (Eine Seite ist eine Zuordnungseinheit in SQLServer und auf 8000 Byte + etwas Overhead festgelegt. Das Überschreiten ist nicht schwerwiegend, aber es fällt auf, und Sie sollten versuchen, dies zu vermeiden, wenn Sie dies leicht können.)
• Viele andere interne Datenstrukturen, Puffer und nicht zuletzt Ihre eigenen Variablen und Tabellenvariablen müssen diese Größen widerspiegeln. Bei übermäßigen Größen kann eine übermäßige Speicherzuweisung die Leistung beeinträchtigen

Versuchen Sie in der Regel, mit der Spaltenbreite konservativ umzugehen. Wenn es zu einem Problem wird, können Sie es leicht erweitern, um es den Anforderungen anzupassen. Wenn Sie später Speicherprobleme bemerken, kann es später unmöglich werden, eine breite Spalte zu verkleinern, ohne Daten zu verlieren, und Sie wissen nicht, wo Sie anfangen sollen.

Überlegen Sie in Ihrem Beispiel für die Firmennamen, wo Sie sie anzeigen können. Gibt es wirklich Platz für 500 Zeichen? Wenn nicht, macht es wenig Sinn, sie als solche zu speichern. http://en.wikipedia.org/wiki/List_of_companies_of_the_United_States listet einige Firmennamen auf und die maximale Anzahl beträgt ca. 50 Zeichen. Also würde ich 100 für die Spalte max verwenden. Vielleicht eher wie 80.

Idealerweise möchten Sie kleiner werden, bis zu einer angemessenen Größe (500 ist nicht ausreichend groß) und sicherstellen, dass die Client-Validierung abfängt, wenn die Daten zu groß werden, und einen nützlichen Fehler senden.

Während der varchar tatsächlich keinen Speicherplatz in der Datenbank für den nicht verwendeten Speicherplatz reserviert, erinnere ich mich an Versionen von SQL Server, bei denen es darum geht, dass Datenbankzeilen breiter als eine bestimmte Anzahl von Bytes sind (nicht an die genaue Anzahl erinnern) und tatsächlich weggeworfen werden Welche Daten auch immer nicht passten. Eine bestimmte Anzahl dieser Bytes war für interne SQL Server-Aufgaben reserviert.