Quando si aumenta la dimensione della colonna VARCHAR su una tabella di grandi dimensioni, potrebbero esserci problemi?

87

Sto usando SQL Server 2008 e ho bisogno di ingrandire un campo VARCHAR, da (200 a 1200) su una tabella con circa 500k righe. Quello che devo sapere è se ci sono problemi che non ho considerato.

Userò questa dichiarazione TSQL:

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

L'ho già provato su una copia dei dati e questa affermazione non ha avuto effetti negativi che ho potuto vedere.

Quindi ci sono possibili problemi nel fare questo che potrei non aver considerato?

A proposito, la colonna non è indicizzata.

— Paul T Davies
fonte

1

@nonnb: questa è un'idea orribile. stackoverflow.com/q/2091284/27535

— gbn

@gbn qualche idea sulla recente risposta di Justin a questa domanda? Sembra essere in qualche modo in contrasto con il tuo.

— AakashM

@AakashM: ha ragione riguardo all'archiviazione ma è un sovraccarico, non un'ottimizzazione. Ora leggi questo stackoverflow.com/q/2009694/27535

— gbn

@gbn - buon punto, così come l'osservazione di Martin Smith sull'indicizzazione. Ritirato.

— StuartLC

2

Si scopre che alla fine c'è stato un trucchetto! Il campo è stato indicizzato e quando qualcuno ha provato a inserire una voce più grande di 900b non è riuscito! Stai attento.

— Paul T Davies,

59

Questa è solo una modifica dei metadati: è veloce.

Un'osservazione: specifica NULL o NOT NULL in modo esplicito per evitare "incidenti" se una delle impostazioni SET ANSI_xx è diversa ad es. Esegui in osql non SSMS per qualche motivo

— gbn
fonte

1

Tutto è andato bene con questo. Nessun problema.

— Paul T Davies,

Sai se valgono le stesse regole quando si va dal varchar(200)a varchar(max)?

— CodeNaked

@ CodeNaked: è molto più complicato rispondere. (max) è un tipo LOB che può essere "in riga" o esterno alla riga. Tuttavia, sono propenso a dire che dovrebbe essere lo stesso perché i dati sono già "in riga" e non sarebbe necessaria alcuna ricostruzione della tabella

— gbn

12

Volevo solo aggiungere i miei 2 centesimi, da quando ho cercato su Google questa domanda b / c mi sono trovato in una situazione simile ...

ATTENZIONE che mentre passare da varchar(xxx)a varchar(yyy)è davvero un cambiamento di metadati, ma cambiare a varchar(max)non lo è. Perché i varchar(max)valori (noti anche come valori BLOB - immagine / testo ecc.) Sono memorizzati in modo diverso sul disco, non all'interno di una riga della tabella, ma "fuori riga". Quindi il server impazzirà su un grande tavolo e non risponderà per minuti (ore).

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

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

PS. lo stesso vale per nvarcharo naturalmente.

— jazzcat
fonte

4

Il passaggio a Varchar (1200) da Varchar (200) non dovrebbe causare problemi poiché si tratta solo di una modifica dei metadati e poiché SQL Server 2008 tronca spazi vuoti eccessivi, non dovresti vedere differenze di prestazioni, quindi in breve non dovrebbero esserci problemi con la creazione del modificare.

— Kprice84
fonte

Credo che questo possa essere vero per le tabelle piccole, ma per le tabelle di grandi dimensioni che vengono interrogate attivamente ciò potrebbe bloccarsi per una quantità di tempo significativa (poiché il server SQL deve vedere se è necessario troncare ogni riga).

— CodeNaked

0

Un altro motivo per cui dovresti evitare di convertire la colonna in varchar (max) è perché non puoi creare un indice su una colonna varchar (max).

— psikorski
fonte

-3

Nel mio caso la colonna di modifica non funzionava, quindi è possibile utilizzare il comando "Modifica", ad esempio:

altera tabella [nome_tabella] MODIFICA colonna [nome_colonna] varchar (1200);

— Gourav Singla
fonte

5

Questo perché non stai utilizzando SQL Server per la domanda (ma MySQL, probabilmente). "ALTER TABLE ... MODIFY" non è un T-SQL valido.

— Jeroen Mostert