sql >> Databáze >  >> RDS >> Sqlserver

Jedinečný identifikátor vs. IDENTITA vs. kód materiálu – která je nejlepší volba pro primární klíč?

GUID se může zdát jako přirozená volba pro váš primární klíč – a pokud opravdu musíte, pravděpodobně byste mohli argumentovat, že jej použijete pro PRIMÁRNÍ KLÍČ tabulky. Co bych důrazně doporučil nedělat je použít GUID jako klastrovací klíč , což SQL Server dělá ve výchozím nastavení, pokud mu výslovně neřeknete, že to tak není.

Opravdu potřebujete oddělit dva problémy:

  1. primární klíč je logická konstrukce – jeden z kandidátských klíčů, který jednoznačně a spolehlivě identifikuje každý řádek ve vaší tabulce. Může to být opravdu cokoliv - INT , GUID , řetězec – vyberte, co má pro váš scénář největší smysl.

  2. klastrovací klíč (sloupec nebo sloupce, které definují „shlukovaný index“ v tabulce) – toto je fyzický věc související s úložištěm a tady je nejlepší volbou malý, stabilní a stále se zvyšující datový typ - INT nebo BIGINT jako výchozí možnost.

Ve výchozím nastavení se primární klíč v tabulce serveru SQL také používá jako klíč clusteru - ale nemusí to tak být! Osobně jsem zaznamenal masivní nárůst výkonu při rozdělení předchozího primárního / seskupeného klíče založeného na GUID na dva samostatné klíče – primární (logický) klíč na GUID a klastrovací (objednávkový) klíč na samostatném INT IDENTITY(1,1) sloupec.

Jako Kimberly Tripp královna indexování - a jiní již mnohokrát uvedli - GUID protože klastrovací klíč není optimální, protože kvůli své náhodnosti povede k masivní fragmentaci stránek a indexů a obecně špatnému výkonu.

Ano, já vím – existuje newsequentialid() v SQL Server 2005 a novějších – ale ani ten není skutečně a plně sekvenční, a proto také trpí stejnými problémy jako GUID - jen trochu méně nápadně.

Pak je tu další problém, který je třeba zvážit:shlukovací klíč v tabulce bude přidán také ke každé položce na každém neklastrovaném indexu ve vaší tabulce – opravdu se chcete ujistit, že je co nejmenší. Obvykle INT s více než 2 miliardami řádků by mělo stačit pro velkou většinu tabulek – a ve srovnání s GUID jako klastrovací klíč si můžete ušetřit stovky megabajtů úložiště na disku a v paměti serveru.

Rychlý výpočet - pomocí INT vs. GUID jako primární a shlukovací klíč:

  • Základní tabulka s 1 000 000 řádky (3,8 MB vs. 15,26 MB)
  • 6 neklastrovaných indexů (22,89 MB vs. 91,55 MB)

CELKEM:25 MB vs. 106 MB - a to jen na jednom stole!

Ještě pár podnětů k zamyšlení – vynikající věci od Kimberly Tripp – přečtěte si to, přečtěte si to znovu, strávte to! Je to skutečně evangelium indexování SQL Serveru.

Pokud k tomu nemáte velmi dobrý důvod , argumentoval bych pro použití INT IDENTITY pro téměř každou „skutečnou“ datovou tabulku jako výchozí pro jejich primární klíč – je jedinečná, je stabilní (nikdy se nemění), je úzká, neustále se zvětšuje – všechny dobré vlastnosti které chcete mít v klastrovacím klíči pro rychlý a spolehlivý výkon vašich tabulek SQL Server!

Pokud máte nějakou „přirozenou“ hodnotu klíče, která má také všechny tyto vlastnosti, můžete ji také použít místo náhradního klíče. Ale dva řetězce s proměnnou délkou max. 20 znaků každý podle mého názoru tyto požadavky nesplňuje.



  1. Použití zpětných značek kolem názvů polí

  2. Aktualizujte stejná data ze stejné tabulky

  3. Pomalý poddotaz v MySQL

  4. Funkce MySQL pro zjištění počtu pracovních dnů mezi dvěma daty