Używanie rozmiaru kolumny znacznie większego niż to konieczne


16

Tworzę bazę danych SQL Server z kimś innym. Jedna z tabel jest mała (6 wierszy) z danymi, które prawdopodobnie pozostaną stałe. Istnieje zdalna możliwość dodania nowego wiersza. Tabela wygląda mniej więcej tak:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Patrzę na długość char tej namekolumny i myślę, że jej wartości prawdopodobnie nigdy nie będą większe niż, powiedzmy, 32 znaki, może nawet nie większe niż 24. Czy jest jakaś korzyść z mojej zmiany tej kolumny na, na przykład varchar(32)?

Ponadto, czy jest jakaś zaleta w utrzymywaniu domyślnych rozmiarów kolumn do wielokrotności 4, 8, 32 itd.?

Odpowiedzi:


15

SQL Server używa długości kolumn podczas przydzielania pamięci do przetwarzania zapytań. Krótko mówiąc, zawsze powinieneś zawsze dopasowywać kolumny odpowiednio do danych.

Przydziały pamięci są oparte na liczbie wierszy zwróconych przez zapytanie pomnożonych przez połowę zadeklarowanej długości kolumny.

Powiedziawszy to, w tym przypadku, gdy masz 6 wierszy, prawdopodobnie nie chcesz przedwcześnie optymalizować. Jeśli nie dołączysz do tej tabeli z milionami wierszy, nie będzie ogromnej różnicy między varchar (24) a varchar (32), a nawet varchar (128).

Drugie pytanie dotyczy wyrównania długości kolumn w wielokrotnościach binarnych. Nie jest to wcale wymagane, ponieważ SQL Server przechowuje wszystkie dane na stronach o wielkości 8 KB, niezależnie od długości każdej kolumny.


14

Przy 6 rzędach nie, nie będzie widocznych korzyści. Cały stół zmieści się na jednej stronie, dzięki czemu zmniejszy się maksymalna potencjalna przestrzeń, którą wykorzystasz na tej stronie, a jednocześnie zajmujesz całą stronę, tak naprawdę nie różni się praktycznie pod każdym względem.

Jednak przy większych stołach kluczowe znaczenie ma dobranie odpowiedniego rozmiaru. Powodem jest to, że szacunki pamięci będą oparte na założeniu, że każda wartość będzie wypełniona w 50%. Więc jeśli masz varchar (128), każda wartość będzie zajmować 64 bajty, niezależnie od rzeczywistych danych, dlatego przydziały pamięci będą wynosić 64b * liczba wierszy. Jeśli wszystkie wartości będą miały maksymalnie 32 znaki, lepszym wyborem jest prawdopodobnie varchar (64) lub nawet varchar (32). Jeśli duży procent wartości jest bliski lub górny, możesz nawet argumentować, że char wyeliminuje z tego zmienność.

Jeśli chodzi o korzyści wynikające z ograniczenia długości łańcucha przy potędze 2, nie sądzę, aby na dzisiejszym sprzęcie ktoś mógł wykazać oczywiste zalety.

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.