Hente alle eller kun feltene man skal bruke (mySQL)

[simenss]

Si at man har en mySQL-database med f.eks. 20 felter (fornavn, etternavn, adresse, id osv.). Hvis man skal hente ut fornavn og etternavn, hvilken av disse to spørringene bør man da kjøre?

 

SELECT fornavn, etternavn FROM tabell

 

eller:

 

SELECT * FROM tabell

 

Er det noen store fordeler/ulemper ved hver av de to spørringene?

Endret 14. april 2008 av simenss

[j--]

Hent kun det du trenger, og ikke noe mer. Det er dumt å legge seg til de vanene at man skal hente alt. Grunnen er det at det blir mer data å overføre/behandle, jo mer du henter. Dumt å hente masse data som man ikke trenger

[roac]

Enig med Hilde, du henter ut det du skal ha, verken mer eller mindre. Det er i hovedsak to grunner til dette: For det første slipper du å overføre mere data enn du trenger, og for det andre vil du i en del tilfeller se at du kan hente alle dataene rett fra indeksen, og at tabellen følgelig ikke blir brukt når du henter ut dataene. Dette er langt mer effektivt.

[simenss]

og for det andre vil du i en del tilfeller se at du kan hente alle dataene rett fra indeksen, og at tabellen følgelig ikke blir brukt når du henter ut dataene.

Kunne du forklart dette nærmere? Hvilken indeks?

[roac]

og for det andre vil du i en del tilfeller se at du kan hente alle dataene rett fra indeksen, og at tabellen følgelig ikke blir brukt når du henter ut dataene.

Kunne du forklart dette nærmere? Hvilken indeks?

Den du evt oppretter. Søk litt på google etter indeksering og MySQL, så finner du sikkert litt informasjon

[simenss]

Den du evt oppretter. Søk litt på google etter indeksering og MySQL, så finner du sikkert litt informasjon

Aha, selvfølgelig.. Stryk det spørsmålet Man trenger ikke gjøre noe spesielt med spørringen dersom den henter dataene rett fra indeksen? Dersom i dette tilfellet fornavn og etternavn ligger i indeksen, kan man bare kjøre SELECT fornavn, etternavn FROM tabell?

[blackbrrd]

Enig med Hilde, du henter ut det du skal ha, verken mer eller mindre. Det er i hovedsak to grunner til dette: For det første slipper du å overføre mere data enn du trenger, og for det andre vil du i en del tilfeller se at du kan hente alle dataene rett fra indeksen, og at tabellen følgelig ikke blir brukt når du henter ut dataene. Dette er langt mer effektivt.

Det gjelder ikke databaser hvor synligheten av raden ikke ligger i indeksen, som i f.eks postgresql...

[JohndoeMAKT]

Det er klart at du bare henter det du trenger, "SELECT *"-kulturen er en uting. En annen ting som ikke er nevnt er i det du skal gjøre noe med data som å sortere eller joine sett så trenger du færre datablokker til hele settet og du vil kunne behandle flere rader før du går over til filsortering og andre trege ting som skjer når du behandler store mengder data.

 

En annen fordel som kan nevnes i forbindelse med store applikasjoner og servere som kjører flere applikasjoner er at godt beskrivende spørringer er lettere å debugge vha "show processes". Om du i slow query log eller i prosesslisten ser ser 2000 "SELECT * FROM users" er det ikke godt å vite hvilken spørring det er som tar lang tid dersom du bruker den samme teksten mange plasser i koden men om du kan se "SELECT email FROM users" skjer det gjerne bare et par ganger og blir lettere å finne.

 

På en annen side gjør mer spesifike spørringer at du får mindre query cache hit, men alt i alt syntes jeg det er bedre å skrive bedre spørringer enn å håpe at cache redder dagen.

[kaffenils]

På en annen side gjør mer spesifike spørringer at du får mindre query cache hit, men alt i alt syntes jeg det er bedre å skrive bedre spørringer enn å håpe at cache redder dagen.

 

Ikke nødvendigvis. Hvis spørringen må lese data fra clustered index eller table heap så må uansett hele pages leses uansett om du skriver select * from users eller select adresse from users.

[JohndoeMAKT]

Kan du utdype?

[roac]

Ganske enkel teori: Databasefiler er delt opp i sider (pages). I SQL Server er disse 8192 bytes, andre databaser kan også ha andre størrelser. Hvis ikke alle data du ønsker finnes i indeksen, så må databaseserveren lese siden som den aktuelle raden befinner seg i. Om man da tar en projeksjon over et utvalg av kolonner eller ikke har ingen påvirkning på mengden data som skal leses fra disk, siden hele siden uansett må leses.

 

Det kaffenils dog glemmer å nevne, er sortering. Dersom et er en order by, group by eller tilsvarende så vil dataene måtte sorteres, og i dette gjør bruk av tempdb, temporary tablespace eller tilsvarende, og i slike tilfeller vil det være ytelse å hente ved projektere over et utvalg kolonner, siden mengde data som skal sorteres eller grupperes blir mindre.

 

Og så til slutt: Det er en grunn til at included columns dukket opp i MSSQL 2005

[JohndoeMAKT]

Dersom et er en order by, group by eller tilsvarende så vil dataene måtte sorteres, og i dette gjør bruk av tempdb, temporary tablespace eller tilsvarende, og i slike tilfeller vil det være ytelse å hente ved projektere over et utvalg kolonner, siden mengde data som skal sorteres eller grupperes blir mindre.

Og det du skriver er nøyaktig det samme jeg har skrevet.

En annen ting som ikke er nevnt er i det du skal gjøre noe med data som å sortere eller joine sett så trenger du færre datablokker til hele settet og du vil kunne behandle flere rader før du går over til filsortering og andre trege ting som skjer når du behandler store mengder data.

 

Det jeg lurte på var hvilke relevanse det har med query cache da det er den delen av posten min han siterer.

Endret 21. april 2008 av JohndoeMAKT

[kaffenils]

Jeg kommenterte ikke sortering og gruppering (les en gang til hva jeg siterte deg på), men buffer cache. Så lenge spørringen ikke kan basere alle operasjoner på en index, men må gå til clustered index eller table heap for data så vil hele pages (og ergo hele rader) leses fra disk uansett om du skriver select * eller select adresse.

Endret 21. april 2008 av kaffenils

[JohndoeMAKT]

Uff, dårlig quoting av meg. Se hvordan jeg har editert forige post kaffenils.

 

Og du bør også gå tilbake og lese hva du siterte meg på. Jeg nevner ikke buffer cache men query cache.

 

http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

[kaffenils]

Uff, dårlig quoting av meg. Se hvordan jeg har editert forige post kaffenils.

 

Og du bør også gå tilbake og lese hva du siterte meg på. Jeg nevner ikke buffer cache men query cache.

 

http://dev.mysql.com/doc/refman/5.0/en/query-cache.html

 

Hehe. Jeg har nok lest helt feil ja. For det første kjenner jeg ikke til query cache i MySQL. Jobber bare med MSSQL og der finnes det ikke noe tilsvarende query cache. Jeg har heller ikke lest setningen nøye nok ser jeg nå, og dermed så har jeg oppfattet det motsatte av hva du egentlig sa.

 

Nåke kjekt så skjer i Haugesund for tiå da? E sjøl fra Førresfjorden, men har levd i "eksil" i Stavanger i ti år nå.

[JohndoeMAKT]

Jeg var rimelig sikker på at situasjonen var som det ja, query cache er ofte et ukjent dyr selv for MySQL-brukere.

 

Haugesundstatusen er jeg ikke så oppdatert da jeg selv er på mitt fjerde eksilår. :| Jeg kan dog legge til at jeg er fra Kolnes, midt på godsiden av vår kjære Førresfjord.

[blackbrrd]

http://www.mysqlperformanceblog.com/2008/0...h-transactions/

 

The result set can be retrieved from query cache (for statements both inside and outside of transactions) until there is a statement inside transactions which modifies the table. As soon as table is modified in transaction it becomes uncachable by query cache until that transaction is committed. Not only query cache can’t be used inside the same transaction which modified data but also in other concurrent transactions which do not even see the changes done yet

 

La oss si at du vedlikeholder et forum, så vil tabellen som inneholder forumpostene ikke være cachable så lenge noen har begynnt å inserte/update en forumpost, men ikke commitet. For et så stort forum som f.eks diskusjon.no så må vel det være omtrent hele tida?

Endret 21. april 2008 av blackbrrd