Könnten beim Erhöhen der VARCHAR-Spalte in einer großen Tabelle Probleme auftreten?

87

Ich verwende SQL Server 2008 und muss ein VARCHAR-Feld in einer Tabelle mit etwa 500.000 Zeilen von (200 bis 1200) vergrößern. Was ich wissen muss, ist, wenn es Probleme gibt, die ich nicht berücksichtigt habe.

Ich werde diese TSQL-Anweisung verwenden:

ALTER TABLE MyTable
ALTER COLUMN [MyColumn] VARCHAR(1200)

Ich habe es bereits an einer Kopie der Daten versucht und diese Aussage hatte keine negativen Auswirkungen, die ich sehen konnte.

Gibt es also mögliche Probleme, die ich möglicherweise nicht berücksichtigt habe?

Die Spalte ist übrigens nicht indiziert.

— Paul T. Davies
quelle

1

@nonnb: das ist eine schreckliche idee. stackoverflow.com/q/2091284/27535

— gbn

@gbn irgendwelche Gedanken zu Justins jüngster Antwort auf diese Frage? Scheint etwas im Widerspruch zu deiner zu stehen.

— AakashM

@AakashM: Er hat Recht mit der Speicherung, aber es ist ein Overhead, keine Optimierung. Lesen Sie

— gbn

@gbn - guter Punkt, ebenso wie Martin Smiths Beobachtung zur Indizierung. Zurückgezogen.

— StuartLC

2

Es stellte sich heraus, dass es am Ende einen Gotcha gab! Das Feld wurde indiziert, und als jemand versuchte, einen Eintrag größer als 900b einzugeben, schlug dies fehl! Sei gewarnt.

— Paul T Davies

59

Dies ist nur eine Metadatenänderung: Sie ist schnell.

Eine Beobachtung: Geben Sie NULL oder NOT NULL explizit an, um "Unfälle" zu vermeiden, wenn eine der SET ANSI_xx-Einstellungen unterschiedlich ist, z. B. aus irgendeinem Grund in osql und nicht in SSMS ausgeführt wird

— gbn
quelle

1

Damit ging alles gut. Keine Probleme.

— Paul T Davies

Wissen Sie, ob beim Übergang von varchar(200)nach die gleichen Regeln gelten varchar(max)?

— CodeNaked

@CodeNaked: Dies ist viel schwieriger zu beantworten. (max) ist ein LOB-Typ, der "in Zeile" oder außerhalb der Zeile sein kann. Ich bin jedoch geneigt zu sagen, dass es das gleiche sein sollte, da die Daten bereits "in Zeile" sind und keine Tabellenwiederherstellung erforderlich wäre

— gbn

12

Ich wollte nur meine 2 Cent hinzufügen, da ich diese Frage gegoogelt habe, befand ich mich in einer ähnlichen Situation ...

Seien Sie sich bewusst, dass der Wechsel von varchar(xxx)zu varchar(yyy)tatsächlich eine Änderung der Metadaten ist, der Wechsel zu varchar(max)jedoch nicht. Weil varchar(max)Werte (auch bekannt als BLOB-Werte - Bild / Text usw.) auf der Festplatte unterschiedlich gespeichert werden, nicht innerhalb einer Tabellenzeile, sondern "außerhalb der Zeile". Der Server wird also auf einem großen Tisch verrückt und reagiert für Minuten (Stunden) nicht mehr.

--no downtime
ALTER TABLE MyTable ALTER COLUMN [MyColumn] VARCHAR(1200)

--huge downtime
ALTER TABLE MyTable ALTER COLUMN [MyColumn] VARCHAR(max)

PS. Gleiches gilt für nvarcharoder natürlich.

— Jazzkatze
quelle

4

Wenn Sie von Varchar (200) zu Varchar (1200) wechseln, sollten Sie keine Probleme haben, da es sich nur um eine Metadatenänderung handelt. Da SQL Server 2008 übermäßige Leerzeichen abschneidet, sollten Sie auch keine Leistungsunterschiede feststellen. Kurz gesagt, es sollten keine Probleme mit der Erstellung der Veränderung.

— Kprice84
quelle

Ich glaube, dass dies für kleine Tabellen zutrifft, aber für große Tabellen, die aktiv abgefragt werden, kann dies für einen erheblichen Zeitraum blockieren (da SQL Server prüfen muss, ob jede Zeile abgeschnitten werden muss).

— CodeNaked

0

Ein weiterer Grund, warum Sie die Konvertierung der Spalte in varchar (max) vermeiden sollten, ist, dass Sie keinen Index für eine varchar (max) -Spalte erstellen können.

— psikorski
quelle

-3

In meinem Fall funktionierte die Änderungsspalte nicht, so dass man den Befehl 'Ändern' verwenden kann, wie zum Beispiel:

alter table [tabellenname] MODIFY column [spaltenname] varchar (1200);

— Gourav Singla
quelle

5

Das liegt daran, dass Sie SQL Server nicht gemäß der Frage verwenden (aber wahrscheinlich MySQL). "ALTER TABLE ... MODIFY" ist kein gültiges T-SQL.

— Jeroen Mostert