Jak długie kolumny wpływają na wydajność i użycie dysku?


26

W naszym obecnym projekcie po prostu zdarza się zbyt często, że musimy rozszerzyć kolumny o kilka znaków. Od varchar(20)do varchar(30)i tak dalej.

W rzeczywistości, ile to naprawdę ma znaczenie? Jak dobrze jest to zoptymalizowane? Jaki jest wpływ dopuszczenia 100, 200 lub nawet 500 znaków dla normalnych pól „wejściowych”? Wiadomość e-mail może zawierać tylko 320 znaków, więc dobrze - jest tam dobry limit. Ale co zyskam, jeśli ustawię wartość 200, ponieważ nie oczekuję dłuższych adresów e-mail niż to.

Zwykle nasze tabele nie będą miały więcej niż 100 000 wierszy i do 20 lub 30 takich kolumn.

Używamy teraz SQL Server 2008, ale byłoby ciekawe wiedzieć, jak różne bazy danych radzą sobie z tymi problemami.

W przypadku, gdy wpływ jest bardzo niewielki - jak bym się spodziewał, pomocne byłoby uzyskanie dobrych argumentów (zabezpieczonych linkami?), Aby przekonać moją DBA, że ta paranoja długiego pola nie jest tak naprawdę konieczna.

W takim przypadku jestem tutaj, aby się uczyć :-)

Odpowiedzi:


12

Konkretna odpowiedź na twoje pytanie (przynajmniej dla Oracle danych i prawdopodobnie innych baz danych) jest taka, że ​​długość pola nie ma znaczenia, a jedynie długość danych. Nie należy tego jednak wykorzystywać jako czynnika decydującego o tym, czy ustawić pole na jego maksymalną dopuszczalną długość, czy nie. Oto kilka innych kwestii, które należy wziąć pod uwagę przed zwiększeniem wielkości pól.

Formatowanie Każde narzędzie klienckie, które formatuje dane na podstawie wielkości pól, będzie wymagać specjalnych rozważań dotyczących formatowania. Na przykład SQL * Plus Oracle domyślnie wyświetla maksymalny rozmiar kolumn Varchar2, nawet jeśli dane mają tylko jeden znak. Porównać…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Długość złych danych stanowi dodatkowy mechanizm wychwytywania / zapobiegania złym danym. Interfejs nie powinien próbować wstawić 3000 znaków w pole 100 znaków, ale jeśli pole to jest zdefiniowane jako 4000 znaków, może po prostu. Błąd nie zostanie wykryty na etapie wprowadzania danych, ale system może mieć dalsze problemy, gdy inna aplikacja próbuje przetworzyć dane i dławiki. Na przykład, jeśli później zdecydujesz się zaindeksować pole w Oracle, przekroczysz maksymalną długość klucza (w zależności od wielkości bloku i konkatenacji). Widzieć…

create index i1 on f1(a);

Pamięć Jeśli aplikacja kliencka przydziela pamięć przy użyciu maksymalnego rozmiaru, aplikacja przydzieli znacznie więcej pamięci, niż jest to konieczne. Aby tego uniknąć, należy podjąć specjalne rozważania.

Dokumentacja Rozmiar pola stanowi kolejny punkt danych dokumentacji dotyczący danych. Możemy wywołać wszystkie tabele t1, t2, t3 itd. I wszystkie pola f1, f2, f3 itd., Ale poprzez podanie znaczących nazw lepiej rozumiemy dane. Na przykład, jeśli tablica adresów dla firmy z klientami w USA ma pole o nazwie Stan, które jest dwoma znakami, spodziewamy się, że będzie w nim występować skrót dwóch znaków stanu. Z drugiej strony, jeśli pole ma sto znaków, możemy spodziewać się, że w polu pojawi się pełna nazwa stanu.


Biorąc to wszystko pod uwagę, wydaje się rozsądnym być przygotowanym na zmiany. To, że wszystkie nazwy Twoich produktów mieszczą się dziś w 20 znakach, nie oznacza, że ​​zawsze będą. Nie idź za burtę i nie daj 1000, ale zostaw miejsce na prawdopodobną ekspansję.



Dokumentacja jest fajna, którą tu dodałeś, której nigdzie indziej nie widziałem.
jeteon

9

Oto dobry punkt wyjścia dla Ciebie.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

Mogłem źle zrozumieć twoje pierwotne pytanie. Zobaczę, czy mogę znaleźć kilka innych linków w celach informacyjnych.

Oto dobre odniesienie do wyboru typów danych: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Zmiana z varchar (20) na varchar (30) może wydawać się czymś małym, ale musisz dowiedzieć się więcej o tym, jak działają struktury baz danych, aby mieć świadomość potencjalnych problemów. Na przykład przejście do varchar (30) może popchnąć cię poza punkt końcowy twoich kolumn (jeśli wszystkie 30 bajtów się przyzwyczai), które mogą być przechowywane na jednej stronie (mniej niż 8060 bajtów). Doprowadzi to do zwiększenia używanego miejsca na dysku, zmniejszenia wydajności, a nawet dodatkowego obciążenia dzienników transakcji.

Oto link do struktur bazy danych: http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

Oto jeden dla podziału strony i rejestrowania trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

Pomyślałem, że podzielę się innym interesującym punktem, który znalazłem w następującym pytaniu SO:

/programming/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

Oryginalna odpowiedź: Nick Kavadias

Powodem, dla którego NIE należy używać pól maksymalnych lub tekstowych, jest to, że nie można wykonać [odbudowy indeksu online] [1], tj. ODBUDOWAĆ ONLINE = WŁ., Nawet przy SQL Server Enterprise Edition.

[1]: http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx „Przebudowuje indeks online”

Uznałbym to za dużą niedogodność przy arbitralnym dodawaniu kolumn n / varchar (max), a według witryny MS to ograniczenie dotyczące przebudowywania indeksu online pozostaje w SQL Server 2008, 2008 R2 i Denali; więc nie jest to specyficzne dla SQL Server 2005.

Dzięki, Jeff


6

W niektórych przypadkach ilość miejsca przydzielonego na pole varchar wpłynie na ilość pamięci przydzielonej do sortowania w pamięci.

Uważam, że prezentacje na SQLWorkshop.com są prowokujące, ta prezentacja mówi o przypadku, w którym rodzaj zamówienia według rozlewa się do tempdb, ponieważ nie ma wystarczającej ilości pamięci dla pól char / varchar.

http://webcasts2.sqlworkshop.com/webcasts.asp

Ta transmisja internetowa została również przedstawiona jako artykuł na następującej stronie internetowej:

http://www.mssqltips.com/tip.asp?tip=1955

Należy zauważyć, że w tej prezentacji sortowana kolumna nie jest kolumną char / varchar, ale ilość miejsca przydzielonego dla kolumny varchar w pamięci w niektórych przypadkach wpływa na wydajność zapytania.


4

USTAW ANSI_PADDING NA?

W efekcie powstaje wiele białych spacji ...


3

Ma to znaczenie tylko w odniesieniu do miejsca na dysku i długości znaków. Oczywiście wyszukiwanie typów danych char i indeksów tego typu danych będzie działało wolniej niż liczba całkowita, ale to kolejna dyskusja.

Typ danych Varchar jest „zmiennym” typem danych, więc jeśli ustawisz limit varchar (500), jest to maksymalna długość znaków dla tego pola. Minimalna długość może wynosić od 0 do 500. Z drugiej strony deklarowane miejsce na dysku będzie różne dla 10, 30 lub 500 pól znaków.

Czasami przeprowadzałem test dla typu danych varchar (800) i dla wartości pustych użyłem 17 bajtów, a dla każdego wstawionego znaku dodawano jeszcze jeden bajt. Na przykład ciąg znaków o długości 400 znaków zawiera 417 bajtów na dysku.


3

Nie sądzę, że istnieje jakakolwiek różnica między tabelami utworzonymi z kolumnami varchar (20) lub varchar ((8000), o ile faktyczna maksymalna długość wynosi <= 20.

Z drugiej strony, w niektórych przypadkach umożliwienie użytkownikom przechowywania dłuższych ciągów może zachęcić ich do zrobienia tego.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.