sql >> Databáze >  >> RDS >> PostgreSQL

Co je efektivnější smallint nebo character(10)?

Řekl bych, že přidání umělého smallint primární klíč by byl levnější z hlediska úložného prostoru, pokud by byl stůl pečlivě navržen.

smallint trvá 2 bajty, zatímco character(10) (což je, proti intuici, varlena ) obsahující znaky ASCII zabere 14 bajtů.

V tabulce by byly 2 bajty navíc zbytečné, ale nezapomeňte, že budete mít index ve sloupci primárního klíče. Takže indexovaná hodnota bude ve skutečnosti uložena dvakrát:jednou v tabulce, jednou v indexu.

Pro jednoduchost ignorujme n-ticová záhlaví a další režii.

  • Použití ISBN jako primárního klíče bude stát dalších 14 bajtů na řádek tabulky.

  • Přidání smallint primární klíč přidá dva bajty do tabulky a dva do indexu, takže celkem čtyři přidané bajty.

Takže přidání smallint primární klíč by měl šetřit místo .

Problémy se zarovnáním byste neměli ignorovat. Všechny datové typy jsou uloženy na adresách paměti, které jsou násobky určitých mocnin dvou. To vyžadují architektury procesorů. smallint obvykle má zarovnání 2, character má zarovnání 1, zatímco například timestamp má zarovnání 8.

Pokud je tedy vaše tabulka definována jako

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

Data tabulky by pak vypadala takto:

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

Řádek je zarovnán na hranici 8 bajtů a šest bajtů od konce, pokud id na začátek issue_time bude prázdné „vyplňovací bajty“.

Chcete-li jej tedy využít na maximum, budete muset zvážit, v jakém pořadí definujete sloupce.

Proč to všechno není ve skutečnosti příliš relevantní:

Tabulka s 5000 nebo 10000 položkami je bez ohledu na to malá.

Veškeré vynaložené prostředky na optimalizaci prostoru jsou v nejlepším případě zbytečnou mikrooptimalizací.

Ale to, co může být chytrý nápad na plánovacím stole, se může později snadno vymstít:Pokud – na rozdíl od toho, co očekáváte – chcete na stůl uložit 70 000 knih, zjistíte, že smallint nebude stačit, i když povolíte záporné id s. Bolest, kterou budete muset vydržet, když budete muset změnit datový typ primárního klíče a všech cizích klíčů, které na něj odkazují v živém systému, zdaleka převáží jakékoli potěšení, které získáte z ušetření nějakých 100 KB chytrými optimalizacemi.



  1. Najděte nejstarší záznam ve spojení mezi dvěma tabulkami

  2. Jak můžeme v MySQL zjistit, zda je index tabulky seskupený nebo ne?

  3. Django a PostgreSQL sekvence pro autoinkrementaci primárního klíče

  4. Použití r sf::st_write do neveřejného schématu v PostgreSQL