czy istnieje przewaga varchar (500) nad varchar (8000)?

Przeczytałem o tym na forach MSDN i tutaj i nadal nie jestem pewien. Myślę, że to jest poprawne: Varchar (max) będzie przechowywany jako typ danych tekstowych, więc ma wady. Powiedzmy więc, że Twoje pole będzie niezawodnie zawierać mniej niż 8000 znaków. Podobnie jak pole BusinessName w mojej tabeli bazy danych. W rzeczywistości nazwa firmy będzie prawdopodobnie zawsze składać się z (wyciągając numer z mojego kapelusza) 500 znaków. Wygląda na to, że wiele pól varchar, na które natrafiam, mieści się znacznie poniżej 8 tys. Znaków.

Czy powinienem więc uczynić to pole varchar (500) zamiast varchar (8000)? Z tego, co rozumiem w SQL, nie ma różnicy między tymi dwoma. Aby ułatwić sobie życie, chciałbym zdefiniować wszystkie moje pola varchar jako varchar (8000). Czy to ma jakieś wady?

Powiązane: Rozmiar kolumn varchar (nie czułem, że ten odpowiedział na moje pytanie).

Z punktu widzenia przetwarzania nie będzie miało znaczenia użycie varchar (8000) vs varchar (500). To raczej rodzaj „dobrej praktyki”, aby zdefiniować maksymalną długość, jaką pole powinno pomieścić i uczynić varchar taką długością. Jest to coś, co może być pomocne przy sprawdzaniu poprawności danych. Na przykład, nadanie skrótu stanu składającego się z 2 znaków lub kodu pocztowego / pocztowego jako 5 lub 9 znaków. Kiedyś było to ważniejsze rozróżnienie, gdy dane wchodziły w interakcję z innymi systemami lub interfejsami użytkownika, w których długość pola była krytyczna (np. Zestaw danych z płaskim plikiem mainframe), ale obecnie myślę, że jest to bardziej przyzwyczajenie niż cokolwiek innego.

Jednym z przykładów, w którym może to mieć znaczenie, jest to, że może zapobiec optymalizacji wydajności, która pozwala uniknąć dodawania informacji o wersji wierszy do tabel z wyzwalaczami after.

Jest to omówione tutaj w SQL Kiwi

Rzeczywisty rozmiar przechowywanych danych jest nieistotny - liczy się potencjalny rozmiar.

Podobnie w przypadku korzystania z tabel zoptymalizowanych pod kątem pamięci od 2016 r. Możliwe było użycie kolumn LOB lub kombinacji szerokości kolumn, które mogłyby potencjalnie przekroczyć limit inrow, ale z karą.

(Max) kolumny są zawsze przechowywane poza wierszami. W przypadku innych kolumn, jeśli rozmiar wiersza danych w definicji tabeli może przekroczyć 8060 bajtów, SQL Server wypycha największe kolumny o zmiennej długości poza wierszem. Ponownie, nie zależy to od ilości danych, które tam przechowujesz.

Może to mieć duży negatywny wpływ na zużycie pamięci i wydajność

Innym przypadkiem, w którym nadmierne zadeklarowanie szerokości kolumn może mieć duże znaczenie, jest to, czy tabela będzie kiedykolwiek przetwarzana przy użyciu usług SSIS. Pamięć przydzielona dla kolumn o zmiennej długości (innych niż BLOB) jest ustalona dla każdego wiersza w drzewie wykonywania i odpowiada zadeklarowanej maksymalnej długości kolumn, co może prowadzić do nieefektywnego wykorzystania buforów pamięci (przykład) . Chociaż deweloper pakietu SSIS może zadeklarować mniejszy rozmiar kolumny niż źródło, tę analizę najlepiej przeprowadzić z góry i tam wymusić.

W samym silniku SQL Server podobny przypadek jest taki, że podczas obliczania przydziału pamięci do przydzielenia SORToperacji SQL Server zakłada, że varchar(x)kolumny będą średnio zużywać x/2bajty.

Jeśli większość twoich varcharkolumn jest pełniejsza, może to doprowadzić do przeniesienia sortoperacji do tempdb.

W twoim przypadku, jeśli twoje varcharkolumny są zadeklarowane jako 8000bajty, ale w rzeczywistości mają zawartość znacznie mniejszą niż ta, twoje zapytanie otrzyma pamięć, której nie wymaga, co jest oczywiście nieefektywne i może prowadzić do oczekiwania na przydziały pamięci.

Jest to omówione w części 2 prezentacji internetowej dotyczącej warsztatów SQL 1, którą można pobrać stąd lub patrz poniżej.

use tempdb;

CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))

INSERT INTO  T 
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values

SELECT id,name500
FROM T
ORDER BY number

SELECT id,name8000
FROM T
ORDER BY number

Oprócz najlepszych praktyk (odpowiedź BBlake'a)

• Otrzymujesz ostrzeżenia o maksymalnym rozmiarze wiersza (8060) bajtów i szerokości indeksu (900 bajtów) z DDL
• DML umrze, jeśli przekroczysz te limity
• ANSI PADDING ON jest ustawieniem domyślnym, więc możesz w końcu zapisać całe mnóstwo białych znaków

Duże kolumny mają pewne wady, które są nieco mniej oczywiste i mogą Cię złapać nieco później:

• Wszystkie kolumny używane w INDEKSIE - nie mogą przekraczać 900 bajtów
• Wszystkie kolumny w klauzuli ORDER BY nie mogą przekraczać 8060 bajtów. Jest to trochę trudne do uchwycenia, ponieważ dotyczy to tylko niektórych kolumn. Aby uzyskać szczegółowe informacje, zobacz Przekroczono limit rozmiaru wiersza w programie SQL 2008 R2 )
• Jeśli łączny rozmiar wiersza przekracza 8060 bajtów, pojawia się „ wyciek strony ” dla tego wiersza. Może to wpłynąć na wydajność (strona jest jednostką alokacji w SQLServer i jest ustalona na 8000 bajtów + trochę narzutu. Przekroczenie tego nie będzie poważne, ale jest zauważalne i powinieneś spróbować tego uniknąć, jeśli możesz)
• Wiele innych wewnętrznych struktur danych, buforów i wreszcie własne zmienne i zmienne tabel muszą odzwierciedlać te rozmiary. W przypadku nadmiernych rozmiarów nadmierna alokacja pamięci może wpłynąć na wydajność

Zasadniczo staraj się zachować ostrożność przy szerokości kolumny. Jeśli stanie się problemem, możesz go łatwo rozszerzyć, aby dopasować go do potrzeb. Jeśli później zauważysz problemy z pamięcią, późniejsze zmniejszenie szerokiej kolumny może stać się niemożliwe bez utraty danych i nie będziesz wiedział, od czego zacząć.

W swoim przykładzie nazw firm zastanów się, gdzie możesz je wyświetlać. Czy naprawdę jest miejsce na 500 znaków? Jeśli nie, przechowywanie ich jako takich nie ma sensu. http://en.wikipedia.org/wiki/List_of_companies_of_the_United_States zawiera listę niektórych nazw firm, przy czym maksymalna długość to około 50 znaków. Więc użyłbym 100 dla kolumny max. Może bardziej jak 80.

Idealnie byłoby, gdybyś chciał zejść mniej niż to, do rozsądnej długości (500 nie ma rozsądnego rozmiaru) i upewnić się, że weryfikacja klienta złapie, gdy dane będą zbyt duże i wyślą użyteczny błąd.

Podczas gdy varchar w rzeczywistości nie rezerwuje miejsca w bazie danych na niewykorzystane miejsce, przypominam sobie, że wersje SQL Server miały problem z wierszami bazy danych, które są szersze niż pewna liczba bajtów (nie pamiętam dokładnej liczby) i faktycznie wyrzucały wszelkie dane nie pasowały. Pewna liczba tych bajtów była zarezerwowana dla elementów wewnętrznych SQL Server.