sql >> Database teknologi >  >> RDS >> PostgreSQL

Hvad er mere effektivt smallint eller karakter(10)?

Jeg vil sige, at tilføje en kunstig smallint primær nøgle ville være billigere med hensyn til lagerplads, hvis bordet er omhyggeligt designet.

En smallint tager 2 bytes, mens et character(10) (som mod intuitivt er en varlena ) indeholdende ASCII-tegn, vil forbruge 14 bytes.

I tabellen ville de ekstra 2 bytes være spild, men glem ikke, at du vil have et indeks på den primære nøglekolonne. Så den indekserede værdi vil faktisk blive gemt to gange:én gang i tabellen, én gang i indekset.

Lad os for enkelhedens skyld ignorere tupeloverskrifter og andre overheads.

  • Brug af ISBN som primær nøgle vil koste yderligere 14 bytes pr. tabelrække.

  • Tilføjelse af en smallint primær nøgle tilføjer to bytes til tabellen og to til indekset, hvilket giver i alt fire tilføjede bytes.

tilføj en smallint primær nøgle skal spare plads .

Du bør ikke ignorere tilpasningsproblemer. Alle datatyper er lagret på hukommelsesadresser, der er multipla af visse potenser af to. Dette kræves af processorernes arkitekturer. En smallint har typisk alignment 2, character har alignment 1, mens for eksempel timestamp har justering 8.

Så hvis din tabel er defineret som

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

Så ville tabeldataene se sådan ud:

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

Rækken er justeret ved en 8-byte grænse, og de seks bytes fra enden hvis id til begyndelsen af ​​issue_time vil være tomme "padding bytes".

Så for at få mest muligt ud af det, skal du overveje, i hvilken rækkefølge du definerer kolonnerne.

Hvorfor er alt dette ikke særlig relevant i virkeligheden:

En tabel med 5000 eller 10000 poster er lille, uanset hvad.

Enhver, der bruges på at optimere pladsen her, er i bedste fald unødvendig mikrooptimering.

Men hvad der kan være en smart idé på planlægningsbordet, kan nemt give bagslag senere:Hvis du – anderledes end hvad du forventer – vil gemme 70.000 bøger i tabellen, vil du opdage, at en smallint vil ikke være nok, selvom du tillader negativt id s. Den smerte, du bliver nødt til at udholde, når du skal ændre datatypen for en primær nøgle, og alle fremmednøgler, der refererer til den i et live-system, vil langt opveje enhver glæde, du får ved at spare omkring 100 KB ved smarte optimeringer.



  1. ANDROID&PHP - Sådan viser du JSONArray fra MySql ved hjælp af PHP

  2. Spring hver nte resultatrække over i PostgreSQL

  3. Konverter SQL-dump til JSON?

  4. Migrering af PostgreSQL til skyen - Sammenligning af løsninger fra Amazon, Google og Microsoft