Jakie są konsekwencje ustawienia varchar (8000)?

22

Skoro varchar zajmuje miejsce na dysku proporcjonalne do wielkości pola, czy jest jakiś powód, dla którego nie powinniśmy zawsze definiować varchar jako maksimum, np. varchar(8000)Na SQL Server?

Przy tworzeniu stołu, jeśli widzę, że ktoś to robi varchar(100), powinienem powiedzieć, że nie, że się mylisz, co powinieneś zrobić varchar(8000)?

sql-server varchar Aleksandr Levchuk
źródło
Myślę, że musimy tutaj rozróżnić użycie w tworzeniu tabeli i użycie w deklaracjach parametrów procedur przechowywanych. Druga interpretacja znajduje się w moim pytaniu dba.stackexchange.com/questions/1772/…
bernd_k

Odpowiedzi:

18
  • Długość jest ograniczeniem danych (np. CHECK, FK, NULL itp.)
  • Wydajność, gdy wiersz przekracza 8060 bajtów
  • Nie może mieć unikalnego ograniczenia ani indeksu (szerokość kolumny klucza musi wynosić <900)
  • Ustawieniem domyślnym jest SET ANSI PADDING ON = możliwość zapisania wielu końcowych spacji
  • SQL Server przyjmie, że średnia długość to 4000 dla operacji sortowania, alokując pamięć na tej podstawie (trzeba znaleźć link, aby to zrobić, ale rdzewiej mnie, gdy to robię :-)

Podsumowanie: nie rób tego.

gbn
źródło
Wydajność, gdy wiersz przekracza 8060 bajtów . To odnosi się do faktycznie używanych bajtów, a nie do maksymalnych dozwolonych bajtów?
bernd_k
@bernd_k: 8060 = największa ilość danych dla jednego wiersza, która zmieści się na pojedynczej stronie 8192. Uwzględnij narzut wiersza. Reszta (132 bajty) = narzut strony
gbn
Oznacza to, że wydajność maleje, gdy większy rozmiar jest rzeczywiście używany, a nie przez sam fakt, że jego użycie jest dozwolone.
bernd_k
@bernd_k: jakikolwiek spadek wydajności spowodowany jest 1. alokacją pamięci dla sortowania itp. 2. Przepełnienie wiersza (> 8060 bajtów). Fakt posiadania 10 znaków w każdej varchar (8000) nie ma znaczenia, dopóki te warunki są spełnione (SQL będzie ostrzegać o potencjalnych błędów później kluczy indeksowych)
gbn
Czy sortowanie tabeli z kolumną varchar (100) wypełnioną polami o długości 100 bajtów jest warte innego pytania, ponieważ sortowanie przyjmuje średnio 50 znaków?
bernd_k
7

Zakładając, że masz na myśli SQL Server, mogę wymyślić jeden.

Istnieje limit wielkości (8 KB) wiersza w tabeli, a SQL pozwala definiować pola varchar, które teoretycznie mogą przekraczać ten limit. Tak więc użytkownik może otrzymać błędy, jeśli wstawi za dużo danych w polu z tym związanym.

Począwszy od SQL 2K8, możesz przekroczyć ten limit, ale istnieją implikacje dotyczące wydajności .

Ponadto istnieje cała kontrola racjonalności polegająca na ograniczeniu rozmiaru do oczekiwanych danych. Jeśli chcesz mieć nieograniczone pole długości, dlaczego nie przejść z tekstem lub tekstem?

JohnFx
źródło
więc typy danych tekst i ntext są przechowywane w sposób, który nie wpływa na wydajność?
Czad
Te typy nie przyczyniają się tak bardzo do limitu wielkości wiersza 8K w tabeli, ponieważ rzeczywiste dane są przechowywane w osobnej tabeli pod pokrywami zamiast w linii z resztą kolumn. Nadal występuje wpływ na wydajność, ale z różnych powodów. Istnieją również ograniczenia dotyczące obsługi funkcji w tych polach w porównaniu do varchar i nvarchar
JohnFx
tekst i ntext są przestarzałe na korzyść varchar (max).
Phil Helmer
3

Z pewnością zależy to od tego, jakie informacje są przechowywane w terenie?

Niektóre rzeczy będą miały maksymalną długość z wielu powodów, a jeśli musi być maksymalna długość, powinna to być długość twojego pola.

Jeśli teoretycznie nie ma maksymalnej długości, zapytałbym, dlaczego miałby być używany varchar.

Toby
źródło
3

W kontekście baz danych Oracle nauczyłem się, że zawsze użycie najmniejszego rozmiaru pola dla kolumn bazy danych ma jedną pułapkę.

Podczas przenoszenia danych poprzez eksport importu z bazy danych z sortowaniem jednobajtowym do bazy danych z sortowaniem wielobajtowym (np. Oracle XE) długość w bajtach może się zwiększyć, a import danych do tabel utworzonych przez import nie powiedzie się. Oczywiście Oracle ma możliwość zdefiniowania długości varchar2 jako char lub bajt.

Chodzi mi tutaj o to, że nie zawsze rozsądnie jest definiować pole tak, aby zawsze było jak najmniejsze. Widziałem wiele tabel zmian, aby później zwiększyć pole wraz ze zmianami wymagań.

Posiadanie 20% -100% nieużywanego pola z jest tutaj dyskusyjną opcją.

bernd_k
źródło