Vinnaren i pepparkakshustävlingen!
2016-11-23, 21:21
  #1
Medlem
bithaxs avatar
Hej.
Har prövat lägga till unique index på en GUID (uniqueidentifier) kolumn som jag gör lookups på i en tabell med ~100000 rader, men det gör typ ingen skillnad för prestandan. Någon idé vad det kan vara för fel? Är det så att index inte ger så mycket extra för uniqueidentifiers, eller beror det på att lookupsen körs via prepared statements? Skall väll inte spela någon roll för query planning hur man kör ett statement?

Detta som jag gör lookups på är en sk "bussiness key" som kommer från ett annat system, och det jag slår upp är min egen surrogatnyckel och uppdaterar, om den finns, annars stoppar jag in. Ni förstår varför det här blir segt.

Kan det vara så att man måste bygga om indexet när man stoppat in många rader? Säg att tabellen är tom i början och successiv fylls på? Måste jag själv bygga om, eller löser det sig självt?
__________________
Senast redigerad av bithax 2016-11-23 kl. 21:57.
Citera
2016-11-24, 00:47
  #2
Medlem
valter-eggons avatar
Jag har för mig att det automatiskt blir ett index på primärnyckelkolumner. Därför märker du ingen skillnad.

Indexet hålls automatiskt uppdaterat.
Citera
2016-11-24, 10:14
  #3
Moderator
Protons avatar
Citat:
Ursprungligen postat av valter-eggon
Jag har för mig att det automatiskt blir ett index på primärnyckelkolumner. Därför märker du ingen skillnad.

Indexet hålls automatiskt uppdaterat.
Nja...

https://msdn.microsoft.com/en-us/lib...=sql.110).aspx

PN innebär ett automagiskt index ja. För att få reda på eventuella flaskhalsar måste man kolla på den execution plan som SQL server använder, går att klicka fram att inkludera en sådan i management studio.

Kolla efter table spooling och table scan, det är ju 2 av de större bovarna i dramat.
Citera
2016-11-24, 21:10
  #4
Medlem
valter-eggons avatar
Citat:
Ursprungligen postat av Proton
Nja...

https://msdn.microsoft.com/en-us/lib...=sql.110).aspx

PN innebär ett automagiskt index ja. För att få reda på eventuella flaskhalsar måste man kolla på den execution plan som SQL server använder, går att klicka fram att inkludera en sådan i management studio.

Kolla efter table spooling och table scan, det är ju 2 av de större bovarna i dramat.
Du kan väl inte säga Nja när det jag skriver är korrekt?

Sen att man kan tvinga ombyggnad av index och annat gör ju inte att det är fel det jag skriver.

Jag har personligen aldrig behövt bygga om några index pga prestanda problem eller se över några exekveringsplaner. Då har jag ändå jobbat med databaser med bitvis miljoner rader i vissa tabeller.
Citera
2016-11-24, 21:39
  #5
Medlem
Citat:
Ursprungligen postat av valter-eggon
Du kan väl inte säga Nja när det jag skriver är korrekt?

Ditt antagande är fel, hen sa aldrig i beskrivningen att det var primärnycklar utan en kolumn som innefattar GUID värden. Detta innebär ju att det inte behöver vara indexerat.
Citera
2016-11-24, 22:23
  #6
Medlem
valter-eggons avatar
Citat:
Ursprungligen postat av jobolle
Ditt antagande är fel, hen sa aldrig i beskrivningen att det var primärnycklar utan en kolumn som innefattar GUID värden. Detta innebär ju att det inte behöver vara indexerat.
Han skriver att han har en uniqueidentifier. Det tolkar jag som att han menar primärnyckel. Varför skulle han annars ha en GUID-kolumn?

Men han kanske inte har satt den som primärnyckel och då är det naturligtvis inte korrekt det jag säger.
Citera
2016-11-26, 10:45
  #7
Medlem
John-Pauls avatar
Definiera uniqueidentifier (GUID) som nonclustred vid PK / unik och uppdatera statistiken, använd statiska förkompilerade queries. Ger 100 tusen rader dålig prestanda så är det troligen dåligt användande.
__________________
Senast redigerad av John-Paul 2016-11-26 kl. 10:47.
Citera
2016-11-26, 10:52
  #8
Medlem
John-Pauls avatar
Citat:
Ursprungligen postat av valter-eggon
Han skriver att han har en uniqueidentifier. Det tolkar jag som att han menar primärnyckel. Varför skulle han annars ha en GUID-kolumn?

Men han kanske inte har satt den som primärnyckel och då är det naturligtvis inte korrekt det jag säger.

När en uniqueidentifier är PK (så ska den vara nonclustred) så är det vanligt att den då är FK också i samma bas. Fungerar utmärkt och prestandaförlusten mot andra typer som nycklar är låg. Fördelarna med GUID som nycklar är i mitt tycke är överlägsna.
Citera
2016-11-26, 12:00
  #9
Medlem
valter-eggons avatar
Citat:
Ursprungligen postat av John-Paul
När en uniqueidentifier är PK (så ska den vara nonclustred) så är det vanligt att den då är FK också i samma bas. Fungerar utmärkt och prestandaförlusten mot andra typer som nycklar är låg. Fördelarna med GUID som nycklar är i mitt tycke är överlägsna.
Håller med. En stor fördel är att man kan merga två likadana databaser utan massa strul jämfört med om man använt en numerisk räknare.

Det jag blev förvirrad av var när Proton skrev Nja när jag sade att primärnycklar automatiskt får ett index på sig.
Citera
2016-11-26, 20:08
  #10
Medlem
bithaxs avatar
GUIDen är inte PK.

Jag upptäckte dock att jag kollat lite fel, för man söker även på datum i tabellen.
Det är en så kallad SCD (slowly changing dimension) där man sparar originalnyckeln från källsystemet i en separat kolumn "external_id", och den används sedan när man uppdaterar SCDn från källsystemet.

Problemet är väl att, ja , dels söker man på både external_id, start_date och end_date, sedan gör man uppdateringar mellan sökningarna, så det kanske inte kan bli mycket snabbare än det är, då jag tror att uppdateringarna är det som tar mest tid.

Skall ändå ta och sätta index på både external_id, start_date och end_date på alla SCDs så får vi se om de blir något bättre, just nu har jag lite annat jag sysslar med.

Exempel på liknande SCD för er som är intresserade:
https://en.wikipedia.org/w/index.php?title=Slowly_changing_dimension#Type_2:_ add_new_row
__________________
Senast redigerad av bithax 2016-11-26 kl. 20:18.
Citera
2016-11-26, 20:20
  #11
Medlem
bithaxs avatar
Citat:
Ursprungligen postat av John-Paul
Definiera uniqueidentifier (GUID) som nonclustred vid PK / unik och uppdatera statistiken, använd statiska förkompilerade queries. Ger 100 tusen rader dålig prestanda så är det troligen dåligt användande.

Prepared statements är väl alltid "förkompilerade"? Det är det den kör, och en av anledningarna till att jag hade svårt att se vad fan den höll på med för det stod bara exec och olika parametrar i profilern. Nu lyckades jag hitta vart den anropar sp_prepare för just den queryn jag är intresserad av.
__________________
Senast redigerad av bithax 2016-11-26 kl. 20:26.
Citera

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback