SQL Server VARCHAR-Spaltenbreite

Beim Durchsuchen des Webs habe ich widersprüchliche Hinweise gefunden, ob bei der Angabe zu breiter VARCHAR-Spalten Leistungseinbußen auftreten, z. B. bei VARCHAR (255), bei VARCHAR (30) wahrscheinlich.

Ich sehe durchweg Übereinstimmung, dass es einen Leistungseinbruch gibt, wenn die gesamte Zeile 8060 Bytes überschreitet. Ansonsten sehe ich Uneinigkeit.

Ist die Behauptung wahr The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Gibt es bei einer Gesamtzeilenbreite von weniger als 8060 echte Leistungsprobleme beim Überdimensionieren von VARCHAR-Spalten?

Beweis, dass Spaltenbreite wichtig ist

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Welche Konsequenzen hat das Setzen von varchar (8000)?

Beweise, dass die Spaltenbreite keine Rolle spielt

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

Die Frage könnte besser formuliert werden als:

"Was ist der Vorteil, wenn die maximale Länge einer Spalte mit variabler Länge überbestimmt wird?"

Im Allgemeinen gibt es wenig Vorteile und mehrere Nachteile, wie die verschiedenen verknüpften Antworten zeigen. Abgesehen von allen anderen Bedenken sollten Sie berücksichtigen, dass SQL Server nicht Open Source ist: Auf der Grundlage der Informationen, die dem System zur Verfügung gestellt werden, werden viele magische Zahlen und Heuristiken angewendet. Ohne den Zugriff auf den Quellcode könnten wir niemals ganz sicher sein, welche Auswirkungen diese Praxis haben könnte.

In einigen Fällen , in denen die durchschnittliche Länge einer Spalte wesentlich höher ist als die von SQL Server bei der Berechnung der Sortier- / Hash-Speicherzuweisungen angenommenen 50%, kann eine Leistungsverbesserung auftreten, wenn Sie die maximale Länge übermäßig angeben. Dies ist eine zweifelhafte Problemumgehung und sollte wahrscheinlich nur durch ein explizites CASToder CONVERT(mit Kommentaren!) Angewendet werden, anstatt die Definition der Basisspalte zu ändern. Manchmal ist es vorzuziehen, die Abfrage neu zu schreiben, um Schlüssel statt ganzer Zeilen zu sortieren .

Wenn die maximale Zeilengröße möglicherweise das In-Row-Limit überschreitet (auch wenn keine Zeilen vorhanden sind), kann das Löschen von Zeilen zu einer unerwarteten Seitenteilung führen, wenn ein Auslöser vorhanden ist. Aktualisierungen können über denselben Mechanismus auch zur Fragmentierung führen.

SQL Server leistet in den meisten Fällen gute Arbeit, in denen gute und genaue Informationen aus Metadaten bereitgestellt werden. Ich halte es für unklug, dieses Prinzip aus Bequemlichkeit zu kompromittieren. Ein vernünftiger Ansatz besteht darin, einen maximalen Längenwert zu wählen , der den tatsächlich zu speichernden Daten und allenfalls vorhersehbaren Änderungen angemessen ist .

WIE Sie angegeben haben, gibt es bei Verwendung von VARCHAR (30) oder VARCHAR (255) oder höher keinen Leistungsunterschied, solange die Zeilengröße 8060 nicht überschreitet (oder auf was auch immer das Maximum festgelegt ist). Der Vergleich von CHAR zu VARCHAR aus dem verlinkten Artikel ist nicht wirklich relevant. Obwohl ich der Meinung bin, dass Sie nicht mehr Speicherplatz angeben sollten, als Sie wirklich benötigen, wissen Sie in vielen Fällen nicht, wie viel Speicherplatz Sie tatsächlich benötigen werden. Seien Sie also liberal mit VARCHAR - Ich bin mir ziemlich sicher, dass das Erhöhen der Größe von Feldern eine erneute Erstellung der Tabelle erfordert, während das Verringern eine einfache ALTER TABLE-Anweisung ist.