Gibt es irgendwelche Nachteile, wenn man immer nvarchar(MAX) verwendet?

Question

Gibt es in SQL Server 2005 irgendwelche Nachteile, wenn man alle Zeichenfelder zu nvarchar(MAX) macht, anstatt explizit eine Länge anzugeben, z. B. nvarchar(255)? (Abgesehen von dem offensichtlichen Nachteil, dass man die Feldlänge nicht auf Datenbankebene begrenzen kann)

Answer 1

Wie bereits erwähnt, geht es in erster Linie um einen Kompromiss zwischen Speicherplatz und Leistung. Zumindest in den meisten Fällen.

Es gibt jedoch mindestens einen weiteren Faktor, der bei der Wahl von n/varchar(Max) gegenüber n/varchar(n) berücksichtigt werden sollte. Sollen die Daten indiziert werden (z. B. ein Nachname)? Da die MAX-Definition als LOB betrachtet wird, steht alles, was als MAX definiert ist, nicht für die Indizierung zur Verfügung. Und ohne einen Index wird jede Suche, die die Daten als Prädikat in einer WHERE-Klausel einbezieht, zu einer vollständigen Tabellensuche gezwungen, was die schlechteste Leistung ist, die man für Datensuchen bekommen kann.

Answer 2

Das einzige Problem, das ich gefunden habe, ist, dass wir unsere Anwendungen auf SQL Server 2005 entwickeln und in einem Fall müssen wir SQL Server 2000 unterstützen. Ich habe gerade gelernt, dass die harter Weg dass SQL Server 2000 die Option MAX für varchar oder nvarchar nicht mag.

Answer 3

Ein Problem ist, dass MAX nicht immer funktioniert, wenn Sie mit mehreren Versionen von SQL Server arbeiten müssen. Wenn Sie also mit Legacy-DBs oder einer anderen Situation arbeiten, die mehrere Versionen beinhaltet, sollten Sie sehr vorsichtig sein.

Answer 4

1) Der SQL-Server muss mehr Ressourcen nutzen (zugewiesener Speicher und Rechenzeit), wenn er mit nvarchar(max) gegenüber nvarchar(n) arbeitet, wobei n eine für das Feld spezifische Zahl ist.

2) Was bedeutet dies in Bezug auf die Leistung?

Auf SQL Server 2005 habe ich 13.000 Datenzeilen aus einer Tabelle mit 15 nvarchar(max)-Spalten abgefragt. Ich habe die Abfragen wiederholt zeitlich begrenzt und dann die Spalten in nvarchar(255) oder weniger geändert.

Die Abfragen vor der Optimierung dauerten im Durchschnitt 2,0858 Sekunden. Die Abfragen nach der Änderung wurden in durchschnittlich 1,90 Sekunden beantwortet. Das war eine Verbesserung um 184 Millisekunden gegenüber der einfachen select *-Abfrage. Das ist eine Verbesserung von 8,8 %.

3) Meine Ergebnisse stimmen mit einigen anderen Artikeln überein, in denen ein Leistungsunterschied festgestellt wurde. Je nach Datenbank und Abfrage kann der Prozentsatz der Verbesserung variieren. Wenn Sie nicht viele gleichzeitige Benutzer oder sehr viele Datensätze haben, dann wird der Leistungsunterschied für Sie kein Problem darstellen. Der Leistungsunterschied wird jedoch mit zunehmender Anzahl von Datensätzen und gleichzeitigen Benutzern größer.

Answer 5

Meine Tests haben gezeigt, dass es bei der Auswahl Unterschiede gibt.

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;