"Thomas Eriksen" <thomas@hardwareonline.dk> wrote in message
news:3e40465a$0$24686$ba624c82@nntp02.dk.telia.net...
> "Jesper Frank Nemholt" <jfn@dassic.com> skrev i en meddelelse
> news:b1ms44$sh8$1@sunsite.dk...
>
> > Med "forespørgsler" mener du reelle selects eller blot åbne connections
?
> > Det er nok persistant connections. De gør ingen skade. En klient kan
> > genbruge en persistant connection og derved spare tid i connect fasen.
>
> Jeg mener selve selects. Jeg kan se at den kommer med selects heletiden
> (hvad den også bør gøre med 200 brugere online)
OK.
> > Hvilken tabeltype kører du med, ISAM eller InnoDB ?
> > ISAM tabeller er ikke velegnede hvis du har mange inserts, og generelt
er
> > min erfaring at InnoDB tabeller er bedre til stort set alt.
>
> Jeg kører med ISAM, hvorfor ja det må du spørge min programør om
Jeg
> står bare for selve serveren. Men jeg har besluttet mig for at jeg må
finde
> nogle manualer og guides så jeg kan sætte mig mere ind i tingene og få
> optimeret installationen.
OK. ISAM er ikke nødvendigvis dårligt i dit tilfælde. ISAM kan godt give god
performance, man har nogle designmæssige uheldigheder der gør at man hurtigt
render ind i problemer, specielt hvis man har mange inserts i få tabeller.
> > Har du prøvet at køre explain på dine queries for at se om de bruger
dine
> > indexes korrekt ?
>
> Nej Igen jeg er amatør på MySQL tidligere har det bare virket uden jeg
> skulle pille så jeg har ikke brugt meget tid på at sætte mig ind i det.
Jeg
> har dog lige prøvet at slette nogle alle indexes på en af de store tunge
> tabeller og det gav ikke noget fald i hastigheden så noget siger mig at de
> ikke har været optimale.
Afgjort.
Du kan se hvordan dine indexes virker ved at skrive explain foran en query.
Eksempel :
mysql> explain SELECT timecode, usertime, systemtime, waittime, runqueue60
FROM cpu WHERE (systemid = '3') AND timecode BETWEEN '2003-02-04 09:06:05'
AND '2003-02-05 09:06:05' ORDER BY timecode;
+-------+-------+---------------+----------+---------+------+------+--------
----+
| table | type | possible_keys | key | key_len | ref | rows | Extra
|
+-------+-------+---------------+----------+---------+------+------+--------
----+
| cpu | range | combined | combined | 10 | NULL | 754 | where
used |
+-------+-------+---------------+----------+---------+------+------+--------
----+
1 row in set (0.01 sec)
Hvis indexet fungerer så vil MySQL skrive navnet på indexet i key feltet.
Hvis der står NULL eller noget i den stil, så er det fordi MySQL har
vurderet at det ikke var værd at bruge dit index.
Dernæst skal du kigge på hhv. rows og Extra.
Det gælder om at have et database-design og index setup der minimerer rows
mest muligt i en select. Mange result rows koster tid.
I MySQL manualen på
www.mysql.com, i kapitlet der beskriver explain
kommandoen, skriver de lidt om hvad de forskellige felter betyder og hvad
der er godt/skidt for performance.
Her er mit index fra tabellen i eksemplet :
mysql> show index from cpu;
+-------+------------+----------+--------------+-------------+-----------+--
-----------+----------+--------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation |
Cardinality | Sub_part | Packed | Comment |
+-------+------------+----------+--------------+-------------+-----------+--
-----------+----------+--------+---------+
| cpu | 1 | combined | 1 | systemid | A |
4 | NULL | NULL | |
| cpu | 1 | combined | 2 | timecode | A |
90507 | NULL | NULL | |
+-------+------------+----------+--------------+-------------+-----------+--
-----------+----------+--------+---------+
2 rows in set (0.18 sec)
Det er et kombineret index. 2 afgørende faktorer er dels at dette index
matcher de ting man søger på i sine queries. Jeg søger f.eks. altid med
angivelse af systemid og timecode. Derfor indgår disse 2 i mit index.
Dernæst er kardinalitets-faktor vigtig. I min database har jeg få systemids
men mange timecodes. Givet mine selects er der derfor stor forskel på om mit
index er systemid+timecode istedet for timecode+systemid. Det kan man se
direkte i en explain, da denne ender op med langt flere rows med
timecode+systemid end systemid+timecode. Det aktuelle index kan f.eks. på
mit arbejde levere en måneds data i løbet af et par sekunder, mens det
omvendte index, timecode+systemid, tager over 4 minutter og bruger en masse
CPU.
> > Har du prøvet at køre dine queries direkte i MySQL (udenom ODBC) for at
se
> > om der er forskel på performance.
> > Jeg tror ikke det er ODBC der driller.
>
> Jeg tror heller ikke at det er ODBC, men jeg kan da prøve at køre
> forespørgslen direkte i MySQL bare for at se.
>
> > Har du ændret i konfigurationen af MySQL i forhold til den gamle server
?
>
> Den skule være ens med den gamle server
OK.
> > Hvordan er den sat op med buffers, logs etc. ?
>
> standard opsætning direkte fra instalationen.
Det er muligvis i underkanten. MySQL i den normale udgave (på unix
ihvertfald) er meget spartansk konfigureret per default, saa den kan klare
sig med meget lidt RAM. Det koster naturligvis i performance hvis databasen
er stor.
Der er eksempler på alternative konfigurations-filer. De ligger i MySQL's
$HOME directory under :
share/mysql/my-small.cnf
share/mysql/my-medium.cnf
share/mysql/my-large.cnf
share/mysql/my-huge.cnf
Default for MySQL er vist my-small.cnf
Jeg bruger som regel my-large.cnf hjemme og my-huge.cnf på mit arbejde.
Du kan se konfigurationen af MySQL online, noget af den ihertfald, ved at
skrive show variables.
/Jesper