6 svar · 691 visningar · startad av Gimbo
Hej,
Har lite frågor på hur jag skulle kunna effektivisera min user tabell som ser ut enligt nedan:
users [userID, username, password, email]
Kan jag sätta index på userID som är en primär nyckel och har autoincrement? eller kan man bara köra index på namn, kolumner med chars?
hur många kolumner kan man köra index på i en tabell? vad bör man tänka på?
Primär nyckeln är ett index, men det är väl sällan eller aldrig man letar efter userid.
Många och listiga index kan väl kanske vässa söktiderna man måste även ha med i minnet att dom fördyra skrivningarna i databasen.
Med andra ord vad ska du ha tabellen till ;-)...osv
/Hasse
Förstår inte frågan egentligen. UserId är ju det enda som du behöver söka upp för att göra klart med de andra fälten.
Troligt innehåller tabellen inte så många poster och det finns ju inga dubletter.
Det finns över 2M poster i databasen och jag vill optimera sql querysen då jag slår upp en användare så undrar om det gör att göra den kolumnen till index på samma sätt som när man gör en kolumn med char till index, att om det är en användare som börjar på bokstaven C så sorteras allt i kolumenn i bokstavordnin och man pekar på bokstaven C så slipper man loopa hela den kolumen för det är mer än 2M poster som sagt och vi gör konsant uppslag mot den tabellen, vi snackar tusentals uppslag per sekund
Primär nyckeln är ett index, men det är väl sällan eller aldrig man letar efter userid.
Nej, men du använder det troligtvis konstant i varenda JOIN du gör mot User-tabellen så om den är vettigt indexerad eller ej kan göra enorm prestandaskillnad.
Däremot är en PRIMARY KEY alltid ett index, huruvida tabellen också är sorterad efter detta index beror på om indexet ifråga är CLUSTERED. Vanligtvis blir PRIMARY KEY:n klustrad, men man kan (åtminstone i SQL Server) välja att göra någon annan kolumn klustrad. Men då ska man veta vad man gör!
Hej,
Har lite frågor på hur jag skulle kunna effektivisera min user tabell som ser ut enligt nedan:
users [userID, username, password, email]
Kan jag sätta index på userID som är en primär nyckel och har autoincrement? eller kan man bara köra index på namn, kolumner med chars?
hur många kolumner kan man köra index på i en tabell? vad bör man tänka på?
Indexering i databaser är delvis ett härke, därför att man kan beskriva grundprinciper, men någonstans längs vägen hamnar man alltid i att vad du än gör så är det positivt för vissa saker och direkt dåligt för andra så i slutändan är det alltid en avvägning som måste göras i det aktuella fallet. Man kan alltså ibland behöva pröva sig fram.
Vissa saker att tänka på dock:
Du kan ha index på vilken typ som helst så länge databasen kan ordna den. Alltså inte tex image och blob. Däremot kan du ha index på alla siffertyper, bokstav/text-typer, boolska kolumner... Däremot kan det vara mer eller mindre smart ibland och speciellt ska man försöka undvika alltför långa nycklar.
Generellt hjälper index ofta (men inte alltid!) sökningar, medan det förlänger tiden det tar att göra INSERT, UPDATE och DELETE. Ju fler index man har på en tabell, ju fler index måste uppdateras när något ändras och ju fler index provar optimeraren om de hjälper upp frågor som ställs mot tabellen. Det är alltså inte enbart positivt.
Det spelar roll hur dina sökningar ser ut. Alltså hur SQL-frågorna som ställs mot databasen ser ut. Du kan ha hur många fina index som helst, men om du har dåligt formulerad SQL-kod tar det väl så mycket tid ändå. Värre, om dina frågor t.ex. innehåller många OR i villkorsdelar spelar det i alla fall i SQL Server ofta ingen roll vilka index du har, det görs en fullständig table scan i alla fall!
2 miljoner rader... hur mycket är det? Antalet rader säger mindre än hur många kB dina rader tar upp. Om du lagrar 2 miljoner rader i en tabell med 10 heltalskolumner så hittar du infon MYCKET fortare än i en tabell med 3 kolumner definierade som tex NVARCHAR(1000) eftersom varje enskild rad i texttabellen tar upp mycket mer utrymme på disk, och det som tar tid är läsningar (och skrivningar) som går över flera block i minnet. Så ju mer kB per rad, ju fler datablock för tabellen och ju längre tid tar åtkomsten.
Den första frågan du måste ställa dig är: Vilket är viktigast, att sökningar går snabbt eller att INSERT, UPDATE och DELETE gör det? Om svaret är sökningar, måste du först fråga dig vilka fält som sökningar oftast görs mot? Betänk att id-kolumnen säkert används i åtskilliga JOINer, men i övrigt vilka fält söks det oftast efter? Gissningsvis inte email så ofta, eller?
Jag har mer att säga men hinner inte nu.
tack för ditt svar, jag har inga joinar, utan enkla sql satser:
select column1, column2 from table where...
insert...
update...
jag kommer ha så många skrivningar till databasen och så många frågor så jag är tvungen att optimera det hela men vet inte riktgt vad den bästa optimeringen skulle vara kodmässigt? något man bör tänka på förutom att köra select *, vad gäller koden...
OK
Nu tolkade jag UserId som användare, och då har jag sällan dessa mängder i just den tabellen.
Kanske skulle du försöka dig på en halvstatisk tabell. en där du reorganiserad tabellen under nattetid för att just använda den som uppslag under dagen.
Men jag ber om ursäkt jag har aldrig haft 2M användare, trots att jag skrivit stora applikationer, fast mest bara i Sverige ;-)
Så kanske en lite beskrivning av de andra tabellerna, som då måste vara gigantiska, vore på sin plats!
Ingen klocka klingar heller när det gäller ditt Nick, men jag ser ju att du har varit med lika länge som jag ;-)
