Al aumentar el tamaño de la columna VARCHAR en una tabla grande, ¿podría haber algún problema?

87

Estoy usando SQL Server 2008 y necesito hacer un campo VARCHAR más grande, de (200 a 1200) en una tabla con aproximadamente 500k filas. Lo que necesito saber es si hay algún problema que no haya considerado.

Usaré esta declaración TSQL:

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

Ya lo probé en una copia de los datos y esta declaración no tuvo efectos nocivos que pude ver.

Entonces, ¿hay algún problema posible al hacer esto que no haya considerado?

Por cierto, la columna no está indexada.

— Paul T Davies
fuente

1

@nonnb: esa es una idea horrible. stackoverflow.com/q/2091284/27535

— gbn

@gbn ¿Alguna idea sobre la reciente respuesta de Justin a esa pregunta? Parece estar algo reñido con el tuyo.

— AakashM

@AakashM: tiene razón sobre el almacenamiento, pero es una sobrecarga, no una optimización. Ahora lea esto stackoverflow.com/q/2009694/27535

— gbn

@gbn: buen punto, al igual que la observación de Martin Smith sobre la indexación. Retirado.

— StuartLC

2

¡Resulta que al final hubo uno! El campo estaba indexado y cuando alguien intentó ingresar una entrada mayor que 900b, ¡falló! Tenga cuidado.

— Paul T Davies

59

Este es solo un cambio de metadatos: es rápido.

Una observación: especifique NULL o NOT NULL explícitamente para evitar "accidentes" si una de las configuraciones de SET ANSI_xx es diferente, por ejemplo, se ejecuta en osql y no en SSMS por alguna razón.

— gbn
fuente

1

Todo salió bien con esto. No hay problemas.

— Paul T Davies

¿Sabes si se aplican las mismas reglas al pasar del varchar(200)a varchar(max)?

— CodeNaked

@CodeNaked: esto es mucho más complicado de responder. (máx.) es un tipo de LOB que puede estar "en fila" o fuera de la fila. Sin embargo, me inclino a decir que debería ser el mismo porque los datos ya están "en la fila" y no se necesitaría una reconstrucción de la tabla

— gbn

12

Solo quería agregar mis 2 centavos, ya que busqué en Google esta pregunta porque me encontré en una situación similar ...

TENGA EN CUENTA que, si bien cambiar de varchar(xxx)a varchar(yyy)es un cambio de metadatos de hecho, cambiar a varchar(max)no lo es. Porque los varchar(max)valores (también conocidos como valores BLOB - imagen / texto, etc.) se almacenan de manera diferente en el disco, no dentro de una fila de la tabla, sino "fuera de fila". Entonces, el servidor se volverá loco en una mesa grande y no responderá durante minutos (horas).

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

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

PD. lo mismo se aplica a nvarcharo por supuesto.

— Jazzcat
fuente

4

Cambiar a Varchar (1200) desde Varchar (200) no debería causarle ningún problema, ya que es solo un cambio de metadatos y como SQL Server 2008 trunca los espacios en blanco excesivos, tampoco debería ver diferencias de rendimiento, por lo que en resumen no debería haber problemas con cambio.

— Kprice84
fuente

Creo que esto puede ser cierto para tablas pequeñas, pero para tablas grandes que se consultan activamente, esto podría bloquearse durante una cantidad de tiempo significativa (ya que el servidor SQL necesita ver si necesita truncar cada fila).

— CodeNaked

0

Otra razón por la que debe evitar convertir la columna a varchar (max) es porque no puede crear un índice en una columna varchar (max).

— psikorski
fuente

-3

En mi caso, la columna de modificación no funcionaba, por lo que se puede usar el comando 'Modificar', como:

modificar tabla [nombre_tabla] MODIFICAR columna [nombre_columna] varchar (1200);

— Gourav Singla
fuente

5

Eso es porque no está usando SQL Server según la pregunta (pero probablemente MySQL). "ALTER TABLE ... MODIFY" no es T-SQL válido.

— Jeroen Mostert