Czy przy zwiększaniu rozmiaru kolumny VARCHAR na dużym stole mogą wystąpić jakieś problemy?

87

Używam SQL Server 2008 i muszę powiększyć pole VARCHAR, od (200 do 1200) w tabeli zawierającej około 500 tys. Wierszy. Muszę wiedzieć, czy są jakieś problemy, których nie brałem pod uwagę.

Będę używać tego oświadczenia TSQL:

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

Wypróbowałem już to na kopii danych i to stwierdzenie nie miało żadnych złych skutków, które widziałem.

Czy są więc jakieś problemy, których mogłem nie wziąć pod uwagę?

Nawiasem mówiąc, kolumna nie jest indeksowana.

— Paul T. Davies
źródło

1

@nonnb: to okropny pomysł. stackoverflow.com/q/2091284/27535

— gbn

@gbn Jakieś przemyślenia na temat ostatniej odpowiedzi Justina na to pytanie? Wygląda na to, że jest w sprzeczności z twoim.

— AakashM

@AakashM: ma rację co do przechowywania, ale jest to narzut, a nie optymalizacja. A teraz przeczytaj ten stackoverflow.com/q/2009694/27535

— pl

@gbn - słuszna uwaga, podobnie jak obserwacja Martina Smitha na temat indeksowania. Wycofane.

— StuartLC

2

Okazało się, że w końcu był jeden haczyk! Pole zostało zindeksowane, a gdy ktoś próbował wprowadzić wpis większy niż 900b, nie udało się! Być ostrzeżonym.

— Paul T Davies

59

To jest tylko zmiana metadanych: jest szybka.

Spostrzeżenie: jawnie określ NULL lub NOT NULL, aby uniknąć „wypadków”, jeśli jedno z ustawień SET ANSI_xx jest inne np. Z jakiegoś powodu uruchom w osql, a nie SSMS

— gbn
źródło

1

Wszystko poszło dobrze z tym. Bez problemów.

— Paul T Davies

Czy wiesz, czy podczas podróży z varchar(200)do obowiązują te same zasady varchar(max)?

— CodeNaked

@CodeNaked: odpowiedź na to pytanie jest znacznie trudniejsza. (max) to typ LOB, który może znajdować się „w rzędzie” lub poza wierszem. Jednak jestem skłonny powiedzieć, że powinno być tak samo, ponieważ dane są już „w wierszu” i nie będzie potrzebna odbudowa tabeli

— gbn

12

Chciałem tylko dodać moje 2 centy, ponieważ wygooglowałem to pytanie b / c znalazłem się w podobnej sytuacji ...

PAMIĘTAJ, że zmiana z varchar(xxx)na varchar(yyy)to rzeczywiście zmiana metadanych, ale zmiana na varchar(max)nie. Ponieważ varchar(max)wartości (znane również jako wartości BLOB - obraz / tekst itp.) Są przechowywane na dysku inaczej, nie w wierszu tabeli, ale „poza wierszem”. Więc serwer zwariuje na dużym stole i przestanie odpowiadać przez kilka minut (godzin).

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

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

PS. to samo dotyczy nvarcharlub oczywiście.

— jazzcat
źródło

4

Zmiana na Varchar (1200) z Varchar (200) nie powinna spowodować żadnego problemu, ponieważ jest to tylko zmiana metadanych, a ponieważ SQL Server 2008 obcina nadmierne puste miejsca, nie powinno być również żadnych różnic w wydajności, więc w skrócie nie powinno być problemów z tworzeniem zmiana.

— Kprice84
źródło

Uważam, że może to być prawdą w przypadku małych tabel, ale w przypadku dużych tabel, które są aktywnie odpytywane, może to blokować się przez znaczną ilość czasu (ponieważ serwer SQL musi sprawdzić, czy musi obciąć każdy wiersz).

— CodeNaked

0

Innym powodem, dla którego powinieneś unikać konwersji kolumny na varchar (max), jest to, że nie możesz utworzyć indeksu w kolumnie varchar (max).

— psikorski
źródło

-3

W moim przypadku kolumna alter nie działała, więc można użyć polecenia `` Modyfikuj '', na przykład:

alter table [nazwa_tabeli] MODIFY kolumna [nazwa_kolumny] varchar (1200);

— Gourav Singla
źródło

5

To dlatego, że nie używasz SQL Server na pytanie (ale prawdopodobnie MySQL). „ALTER TABLE ... MODIFY” nie jest poprawnym językiem T-SQL.

— Jeroen Mostert