Która jest bardziej wydajna smallint czy character(10)?

Powiedziałbym, że dodanie sztucznego smallint klucz podstawowy byłby tańszy pod względem przestrzeni dyskowej, gdyby tabela była starannie zaprojektowana.

smallint zajmuje 2 bajty, podczas gdy character(10) (co jest, wbrew intuicji, varlena ) zawierające znaki ASCII, zajmie 14 bajtów.

W tabeli dodatkowe 2 bajty byłyby marnotrawstwem, ale nie zapominaj, że będziesz miał indeks w kolumnie klucza podstawowego. Tak więc zindeksowana wartość będzie faktycznie przechowywana dwukrotnie:raz w tabeli, raz w indeksie.

Dla uproszczenia zignorujmy nagłówki krotek i inne narzuty.

• Użycie numeru ISBN jako klucza podstawowego będzie kosztować dodatkowe 14 bajtów na wiersz tabeli.

• Dodawanie smallint klucz główny doda dwa bajty do tabeli i dwa do indeksu, co w sumie daje cztery bajty.

Więc dodanie smallint klucz podstawowy powinien oszczędzić miejsce .

Nie powinieneś ignorować problemów z wyrównaniem. Wszystkie typy danych są przechowywane pod adresami pamięci, które są wielokrotnościami pewnych potęg dwójki. Jest to wymagane przez architektury procesorów. smallint zazwyczaj ma wyrównanie 2, character ma wyrównanie 1, na przykład timestamp ma wyrównanie 8.

Więc jeśli twoja tabela jest zdefiniowana jako

CREATE TABLE book (
   id smallint PRIMARY KEY,
   issue_time timestamp with time zone,
   isbn character(10)
);

Wtedy dane tabeli wyglądałyby tak:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |X|X|X|X|X|X| | | | | | | | | ... (ISBN omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 id    padding     issue_time

Wiersz jest wyrównany do granicy 8 bajtów, a sześć bajtów od końca, jeśli id na początek issue_time będzie puste „bajty dopełnienia”.

Aby jak najlepiej wykorzystać to, musisz rozważyć, w jakiej kolejności definiujesz kolumny.

Dlaczego to wszystko nie jest tak istotne w rzeczywistości:

Tabela z 5000 lub 10000 wpisami jest niewielka, bez względu na wszystko.

Każda myśl poświęcona tutaj optymalizacji przestrzeni jest w najlepszym razie niepotrzebną mikrooptymalizacją.

Ale to, co może być mądrym pomysłem na stole do planowania, może później łatwo odbić się odwrotnym skutkiem:Jeśli – w odróżnieniu od tego, czego oczekujesz – chcesz przechowywać w tabeli 70000 książek, okaże się, że smallint nie wystarczy, nawet jeśli zezwolisz na ujemny id s. Ból, który będziesz musiał znieść, gdy będziesz musiał zmienić typ danych klucza podstawowego i wszystkich kluczy obcych, które odwołują się do niego w aktywnym systemie, znacznie przewyższy przyjemność, jaką możesz uzyskać z zaoszczędzenia około 100 KB dzięki sprytnym optymalizacjom.