Performance......

Normalt vil der ikke være mærkbar forskel, men noget der dog være, da MySQL jo skal hente alle kolonner ind i memory med "SELECT *", hvor den ellers kan nøjes med de to du har brug for.

Generelt er det dog en god ide at undgå "SELECT *" rent kodningsmæssigt, da det så ikke umiddelbart er synligt hvad man får tilbage. Men hvis du har 100 felter, vil jeg nok også vælge "SELECT *" hvis jeg skal bruge over 10-20 felter :-)

Jamen jeg mener, vil der være forskel på om tabellen har 2 eller 100 kolonner.... Vil det tage længere tid at udføre sætningen SQL = "SELECT varenr,betegnelse FROM tabel" hvis tabellen indeholder 100 kolonner end hvis den kun indeholder de to?

Der er 3 potentielle flaske-halse ved database adgang:
1) disk IO på database serveren
2) CPU på database serveren
3) netværk fra database server til client

Dine 2 SQL sætninger må være ens for #1 og #2 - der skal
læses det samme antal records og der skal ikke beregenes
noget.

Men det kan godt betyde lidt for #3 om man henter alle
felter eller kun 2 felter.

Lidt afhængig af netværket og antal rækker. Der er stor
forskel på at hente 100 rækker på 100 Mbit LAN eller
hente 100000000 rækker over 64 Kbit ISDN opkobling.

arne_v> det kan faktisk også betyde noget for disk IO på database serveren.

Jo mindre recorden fylder i database, jo flere records kan der være på en database side, og jo færre IO skal der bruges alt i alt.

I de fleste tilfælde vil det ikke betyde noget nævneværdigt, men det er noget man regner på når man designer high-performance databaseløsninger med store datamængder og stor trafik.

I det konkrete eksempel vil der være ca. 5000 records i databasen..... Skal jeg konkludere, at det ikke vil betyde alverden for min performance at der er mange kolonner i tabellen, når blot jeg i min SQL kun henter de kolonner, jeg skal bruge?

Hvorfor har du 100 kolonner i tabellen? Er der data i alle kolonner i alle rækker eller kan du optimere ved at lave flere tabeller?

5000 records er ingenting :-)  men det er sjældent at der er brug for 100 kolonner i en tabel. Det er ofte mere praktisk at dele det ud på flere tabeller ..

flse.... Ved godt, at det ikke er praktisk med 100 kolonner.... bare for at tage et ekstremt eksempel :-)

Det er helt ok .. jeg har før arbejdet med lønsystemer, hvor flere tabeller havde over 100 felter, så det kan sagtens forekomme. Det er bare sjældendt det er nødvendigt/praktisk. Men det er jo op til folk at beslutte hvad der er bedst for dem selv :-)

flse> Alle database læse så vidt jeg ved data fra disk i
rimeligt store klumper. Det vil normalt betyde, at der
læses præcis de samme data fra disk uanset om det er 2 eller
100 felter man skal bruge. Undtagelsen er BLOB storet
separat og lignende.

arne_v> i en klump på 1MB kan du stadig have flere records hvis recordstørrelsen er 50KB end hvis den er 500KB :-)

Hvis man superoptimerer en database, så beregner med endvidere sidestørrelsen i databasen så den bliver et multiplum af recordstørrelsen plus plads til index (hvis de gemmes fysisk sammen med tabellen).

Jeg har dog ikke set det blive gjort på MySQL databaser, og tror iøvrigt ikke det er muligt (InnoDB tabeller muligvis undtaget).

Og med 5000 records vil det aldrig kunne betale sig at skrue på den slags detajler  ;-)

flse> jeg er helt enig i at det kræver mere disk IO at læse X
records af 50 KB and X records af 500 KB. Men det var ikke det
jeg har udtalt mig om. Jeg siger, at det tager lige så
lang tid at hente 2 felter fra X records af Y KB som det
tager at hente alle felter fra X records af Y KB.

Kom med nogle benchmarks - alle de formodninger og utestede teorier kan ikke bruges.

arne_v> hvis man udelukkende henter data fra en tabel, så har du givetvis ret. Dog vil der være en performanceforskel, hvis man kun selecter nogle felter, som alle står i samme index, så MySQL kan nøjes med at læse indextabellen, og ikke skal læse selve datatabellen.

Hvis man joiner resultatet med andre tabeller, eller laver GROUP BY/ORDER BY som forårsager at databasen skal lave temporære tabeller for at behandle forespørgslen, så vil det påvirke performance.

flse> hvis der er en index med lige præcis de interessante
felter, så kan det minske IO, men det er et special-tlfælde.

Du har også ret m.h.t. temporære tabeller, men jeg henviste
eksplicit til de 2 SQL sætninger som spørgsmålet gik på. Og
de kræver ikke nogle temporære tabeller.

Og det er ikke for at være nit-picky. Med den givne
problem-stilling vil antal-rækker og netværks hastigheden
være de helt afgørende parametre for hvorvidt der er
en forskel på de 2 SQL sætninger.

morw> Der er ikke nogen grund til at benchmarke ting som
er selvindlysende.

iøvrigt kan man i MySQL's my.cnf fil tilføje log-slow-queries optionen, så man kan se hvor lang tid queries faktisk tager, så man kan optimere hvor der er behov for det, og ikke skal gætte sig frem :-)

arne_v> at man har et index med præcis de 2 felter man skal bruge, er ikke noget special tilfælde, hvis det er en ofte forekommende forespørgsel. Jeg laver ofte den slags for at optimere performance på mine databaser.

Men du har ret, præcist den angivne problemstilling, vil det være antal records, samt netværket der betyder noget (hvis altså det ikke køre på samme server).

arne_v> Jeg synes ikke det du skriver er selvindlysende:

<citat>Jeg siger, at det tager lige så
lang tid at hente 2 felter fra X records af Y KB som det
tager at hente alle felter fra X records af Y KB.</citat>

Hvis dit datasæt indeholder flere kb, bruger du mere ram, mere båndbrede mellem mysqlserver og frontend.

Se det lyder selvindlysende ;-D

Hvis du læser alle indlæggene, så vil du se at
den diskussion drejede sig om disk IO (#1 i min liste) !

Og at net-båndbredde netop var en af mine pointer.