Lors de l'augmentation de la taille de la colonne VARCHAR sur une grande table, peut-il y avoir des problèmes?

87

J'utilise SQL Server 2008 et j'ai besoin d'agrandir un champ VARCHAR, de (200 à 1200) sur une table avec environ 500k lignes. Ce que j'ai besoin de savoir, c'est s'il y a des problèmes que je n'ai pas pris en compte.

J'utiliserai cette instruction TSQL:

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

Je l'ai déjà essayé sur une copie des données et cette déclaration n'a eu aucun effet néfaste que je pouvais voir.

Y a-t-il donc des problèmes possibles à faire cela que je n'aurais peut-être pas envisagés?

À propos, la colonne n'est pas indexée.

— Paul T Davies
source

1

@nonnb: c'est une idée affreuse. stackoverflow.com/q/2091284/27535

— gbn

@gbn des pensées sur la réponse récente de Justin à cette question? Semble être quelque peu en désaccord avec le vôtre.

— AakashM le

@AakashM: il a raison sur le stockage mais c'est une surcharge, pas une optimisation. Maintenant, lisez ce stackoverflow.com/q/2009694/27535

— gbn

@gbn - bon point, tout comme l'observation de Martin Smith sur l'indexation. Retiré.

— StuartLC

2

Il s'avère qu'à la fin, il y avait un piège! Le champ a été indexé et lorsque quelqu'un a essayé de saisir une entrée supérieure à 900b, il a échoué! Être averti.

— Paul T Davies

59

Il s'agit uniquement d'un changement de métadonnées: c'est rapide.

Une observation: spécifiez NULL ou NOT NULL explicitement pour éviter les "accidents" si l'un des paramètres SET ANSI_xx est différent, par exemple exécuter dans osql et non SSMS pour une raison quelconque

— gbn
source

1

Tout s'est bien passé avec ça. Pas de problème.

— Paul T Davies

Savez-vous si les mêmes règles s'appliquent lors du passage de varchar(200)à varchar(max)?

— CodeNaked

@CodeNaked: c'est beaucoup plus délicat à répondre. (max) est un type LOB qui peut être "en ligne" ou en dehors de la ligne. Cependant, je suis enclin à dire que cela devrait être la même chose car les données sont déjà "en ligne" et aucune reconstruction de table ne serait nécessaire

— gbn

12

Je voulais juste ajouter mes 2 cents, depuis que j'ai googlé cette question car je me suis retrouvé dans une situation similaire ...

SACHEZ que le passage de varchar(xxx)à varchar(yyy)est un changement de méta-données, mais que le passage à varchar(max)ne l'est pas. Parce que les varchar(max)valeurs (aka valeurs BLOB - image / texte, etc.) sont stockées différemment sur le disque, pas dans une ligne de table, mais «hors ligne». Ainsi, le serveur deviendra fou sur une grande table et ne répondra plus pendant des minutes (heures).

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

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

PS. il en va de même pour nvarcharou bien sûr.

— jazzcat
source

4

Le passage à Varchar (1200) à partir de Varchar (200) ne devrait pas vous poser de problème car il ne s'agit que d'un changement de métadonnées et comme SQL Server 2008 tronque les espaces vides excessifs, vous ne devriez voir aucune différence de performance non plus, donc en bref, il ne devrait y avoir aucun problème à faire le changement.

— Kprice84
source

Je pense que cela peut être vrai pour les petites tables, mais pour les grandes tables qui sont activement interrogées, cela pourrait bloquer pendant un laps de temps significatif (car le serveur SQL doit voir s'il doit tronquer chaque ligne).

— CodeNaked

0

Une autre raison pour laquelle vous devriez éviter de convertir la colonne en varchar (max) est que vous ne pouvez pas créer un index sur une colonne varchar (max).

— psikorski
source

-3

Dans mon cas, modifier la colonne ne fonctionnait pas, donc on peut utiliser la commande 'Modifier', comme:

alter table [nom_table] MODIFY colonne [nom_colonne] varchar (1200);

— Gourav Singla
source

5

C'est parce que vous n'utilisez pas SQL Server pour la question (mais MySQL, probablement). "ALTER TABLE ... MODIFY" n'est pas un T-SQL valide.

— Jeroen Mostert