Bij het ontwerpen van de database gebruiken we vaak guid of int als hoofdsleutel, en volgens de kennis die we hebben opgedaan, hebben we altijd het gevoel gehad dat int efficiënter is als hoofdsleutel, maar onmogelijk zonder zorgvuldig testen
Leg de reden uit. Het gebeurde dat ik tijdens het optimaliseren van de database vandaag dit probleem tegenkwam, dus heb ik een test gedaan.
Testomgeving:
Desktop-pc Pentiun(R) 4 CPU 3,06GHz Win XP professional 1,5G DDR RAM SQL Server 2005 Personal
Testproces:
Maak eerst een testdatabase aan, Test
De testresultaten zijn als volgt:
Zoals hierboven vermeld, is de efficiëntie van het gebruik van int als primaire sleutel verbeterd vergeleken met het gebruik van guid als hoofdsleutel, vooral wanneer er een verbindingsquery is en records worden verwijderd.
Bovendien trad in de dataquery met de hoofdsleutel in GUID vandaag de tijd herhaaldelijk op door het genesten van meerdere subqueryresultaten. Daarom ben ik voor het gebruik van int als hoofdsleutel, en ik ben het niet eens met guid als hoofdsleutel. De bovenstaande opvattingen vertegenwoordigen persoonlijke meningen, en iedereen is welkom om hun mening te uiten en de voor- en nadelen van GUID en INT als belangrijkste sleutel uit te leggen.
Vervolgonderzoeken:
Na herinnering door de broers is er vandaag een niet-geclusterde index toegevoegd aan twee subtabellen:
MAAK NIET-GECLUSTERDE INDEX Index_Detail_Guid AAN Test_Guid_Detail(Guid) MAAK NIET-GECLUSTERDE INDEX Index_Detail_id AAN OP Test_Int_Detail(id) Vervolgens heb ik een interne connectie-query uitgevoerd en ontdekte dat, zoals @Xu Shaoxia zei, de efficiëntie inderdaad niet duidelijk genoeg is om meer dan 50% aan te geven, en in feite slechts ongeveer 23% verbetering, wat nog steeds acceptabel is.
Daarom wordt het aanbevolen
1. In systemen die vaak datamigratie nodig hebben, wordt aanbevolen Guid te gebruiken. En het toevoegen van niet-geclusterde indexen aan de bijbehorende vreemde sleutelvelden, dat wil zeggen velden die worden gebruikt voor join-query's, is van groot voordeel om de prestaties te verbeteren. Het veld van de where-voorwaarde kan ook worden toegevoegd voor niet-geclusterde indexen.
2. Bij het gebruik van het Guid-type als primaire sleutel moet het datatype uniqueidentifier zijn, en vergeet niet de "aggregate index" van de primaire sleutel te annuleren
3. Voor systemen die niet hoeven te worden gemigreerd, of voor kleine systemen, is het nog steeds erg handig om int als primaire sleutel te gebruiken, en is er nog steeds een zekere verbetering in efficiëntie.
|