Avatar billede spuncut Nybegynder
01. november 2004 - 10:30 Der er 33 kommentarer og
1 løsning

Langsom MySQL 4.17

Server : 1,1 GHz AMD, 768Mb RAM, Windows 2000 Server, MySQL 4.17

Tabel :
CREATE TABLE `s_dk` (
  `ID` int(11) NOT NULL auto_increment,
  `Domain` varchar(255) default NULL,
  `State` int(11) default '0',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1


Totalt antal records : 36189

Følgende SQL
SELECT * FROM s_dk WHERE Domain LIKE '%a%' ORDER BY (IF(Domain LIKE '%a%', 1, 0)) DESC LIMIT 18880, 20
kan tage mellem 0,7 - 1,3 sekunder..!!!

Jeg har prøvet at installere MySQL 4.17 på en anden PC med en 2,4 GHz AMD og Windows 2000 prof. hvilket KUN resulterer i at søgningen bliver ca. dobbelt så hurtig.
Herefter prøvede jeg at koble op til en MySQL version 4.016 over internettet (512kbps) hvilket reducerede søgetiden til ca. en tiendedel..!!!

Er MySQL 4.17 noget skrammel..??
Jeg havde samme ballade med ver. 5.0 derfor prøvede jeg at skifte til 4.17...
Eller har jeg installeret en uheldig windows update ..??
Eller nogen andre forslag..??
Avatar billede spuncut Nybegynder
01. november 2004 - 10:34 #1
Lige en ting til :
MySQL servicen startes med optionen : -- old_password
for kompatibilitet med ODBC 3.51.
Kunne det evt. være et problem...??
Avatar billede peterwr Nybegynder
01. november 2004 - 10:36 #2
Hej,

Du mangle (næsten) uden tvivl at lave et index på "domain" - det er den normale årsag hvis jeg har hastighedsproblemer - uden index skal MySQL jo søge alle records igennem en-for-en.

Med venlig hilsen
Peter
Avatar billede spuncut Nybegynder
01. november 2004 - 10:39 #3
citat : ....Herefter prøvede jeg at koble op til en MySQL version 4.016 over internettet (512kbps) hvilket reducerede søgetiden til ca. en tiendedel..!!!
Samme database..!!!
Avatar billede erikjacobsen Ekspert
01. november 2004 - 10:44 #4
Det er ikke helt fair at sammenligne hastighed med en konstruktion som
WHERE Domain LIKE '%a%'
der skal løbe alt igennem, og ikke kan udnytte et evt index. Men forklaringen
er måske at mysql til windows ikke kommer på højde med mysql til unix-lignende
platforme. Din mysql på nettet kørte vel ikke windows?
Avatar billede spuncut Nybegynder
01. november 2004 - 10:49 #5
..Den jeg prøvede over nettet er en AMD Duron 1,3 GHz, 768MB(PC133), Windows 2000 prof. (ikke Server)...Forskellen er kun MySQL versionen....4.17 her hos mig og 4.016 hos min makker i den anden ende af en 512Kbps ADSL....
Avatar billede majkat Nybegynder
01. november 2004 - 11:17 #6
Hvorfor i alverden har du den ORDER BY på? Du har jo via din WHERE allerede sørget for at den altid returnerer 1...

Du tvinger MySQL til at gennemløbe samtlige 36189 records flere gange, så der er ikke noget at sige til det er langsomt.

Prøv først og fremmest at fjerne din ORDER BY.

Du kan ikke sammenligne installationer/versioner udelukkende på baggrund af RAM og processorhastighed. Der er sikkert indstillinger i opsætningen på de to maskiner som er vildt forskellige. Prøv at køre SHOW VARIABLES på begge maskiner og sammenlign.
Avatar billede spuncut Nybegynder
01. november 2004 - 11:37 #7
...jo det lyder grangiveligt som alle records bliver gennemløbet i ver 4.17 men det ser ikke ud til at ske i ver 4.016....Hvilke parametre skal jeg være særlig opmærksom på..?? De hedder ikke det samme.
Avatar billede majkat Nybegynder
01. november 2004 - 12:01 #8
prøv først med SHOW VARIABLES LIKE "%buffer%" og SHOW VARIABLES LIKE "%cache%"
Avatar billede majkat Nybegynder
01. november 2004 - 12:02 #9
har du i øvrigt prøvet forslaget med at fjerne ORDER BY?
Avatar billede sjh Nybegynder
01. november 2004 - 12:05 #10
majkat > er der forskel på SQL string fra 4.016 til 4.17??

Jeg skulle da mene at den samme SQL string ville give samme resultat om du køre den på v4.016 eller v4.17??
Avatar billede spuncut Nybegynder
01. november 2004 - 12:28 #11
Avatar billede sjh Nybegynder
01. november 2004 - 12:48 #12
SHOW VARIABLES : v4.0.16
http://wonder.sjhdata.dk/amd1300.php
Avatar billede majkat Nybegynder
01. november 2004 - 12:49 #13
sjh> forstår ikke helt dit spørgsmål. Mener jeg, der er forskel mellem hvordan 4.0 og 4.1 håndterer den ORDER BY? Nej, det gør jeg ikke -- men det ændrer ikke på, at den koster dyrt og er fuldstændigt unødvendig.

spuncut> ja, og så? Hvor er sammenligningen med den server du siger der er hurtig? Hvor er forskellene?
Avatar billede spuncut Nybegynder
01. november 2004 - 12:52 #14
Ja den kom så fra sjh...
Avatar billede sjh Nybegynder
01. november 2004 - 12:52 #15
ha ha det er min :D
SHOW VARIABLES : v4.0.16
http://wonder.sjhdata.dk/amd1300.php
Avatar billede spuncut Nybegynder
01. november 2004 - 12:56 #16
Altså :
Den hurtige 4.0.16 : http://wonder.sjhdata.dk/amd1300.php
Den sløve 4.1.7 : http://spuncut.lir.dk/mysql/default.asp
..are you with..??
Avatar billede majkat Nybegynder
01. november 2004 - 13:44 #17
Jeg er med.

Er du?

Prøvede du f.eks. at fjerne den ORDER BY som jeg foreslog fra starten?

Prøv at lægge mærke til disse forskelle:

read_buffer_size
- langsomme:  61440
- hurtige:    131072

Den langsomme har kun en halvt så stor buffer til at cache læsninger fra disk - så den skal stå og vente på disken ca. dobbelt så mange gange som den hurtige.

sort_buffer_size
- langsomme:  262136
- hurtige:  2097144

Den hurtige har 10x så meget plads some den langsomme til at foretage sorteringer (herunder ORDER BY). Den langsomme skal med stor sandsynlighed skrive og læse til/fra disken under sortering, mens den hurtige kan have det hele i RAM.

Men tag nu lige og test uden den der ORDER BY først, inden du går i gang med at pille ved server indstillingerne.
Avatar billede spuncut Nybegynder
01. november 2004 - 15:52 #18
ORDER BY'en giver ca 20 %, fint nok.. men jeg er ikke helt sikker på at jeg kan undvære den ved søgning på flere ord.. mere om det senere.

MEN bufferne rykker 1000%  !!!!

> majkat : smid et svar

Jeg vender tilbage når jeg har fintunet buffer-parametrene.
tnx
Avatar billede spuncut Nybegynder
01. november 2004 - 16:06 #19
Før kunne det tage op til 5 sekunder processing time at få denne side :
http://spuncut.lir.dk/pages/default.asp?page=1085&search=a%20b&range=10&pgesize=20
..hvor den går til sidste side i et resultat-sæt.
Avatar billede majkat Nybegynder
01. november 2004 - 19:29 #20
.
Avatar billede spuncut Nybegynder
02. november 2004 - 01:57 #21
Det er "sort_buffer_size" som giver noget, den er nu sat til 64Mb.
Hvilket ca. har reduceret processing time til ca en tiendedel, ca. 450ms.
http://spuncut.lir.dk/pages/default.asp?page=1809&search=s%20a&range=10&pgesize=20
Ved søgning på flere ord er den omtalte ORDER BY desværre nødvendig, men jeg har
fjernet den ved søgning på eet ord hvilket reducerer pt til lidt under 200ms.
http://spuncut.lir.dk/pages/default.asp?page=1809&search=s&range=10&pgesize=20
Jeg takker MVH
Avatar billede spuncut Nybegynder
02. november 2004 - 02:03 #22
point til majkat
Avatar billede majkat Nybegynder
02. november 2004 - 07:17 #23
Tak for point.

Af ren nysgerrighed: kan flg. måske være en mere effektiv query?

SELECT *, IF(Domain LIKE '%a%', 1, 0) +
          IF(Domain LIKE '%b%', 1, 0) +
          IF(Domain LIKE '%c%', 1, 0) AS score
FROM s_dk
HAVING score > 0
ORDER BY score DESC LIMIT 18880, 20

Min umiddelbare antagelse er, at hvis der vælges mange records til visning vil dette være mere effektivt -- men hvis der kun udvælges en lille procentdel, så vil det i værste fald være en smule langsommere end den oprindelige query.

Lagde i øvrigt mærke til at query cache er 0 på begge servere. Foreslår at du læser lidt op på dette emne.
Avatar billede spuncut Nybegynder
02. november 2004 - 08:14 #24
Underligt: query_cache_size=20 i ini-filen
Avatar billede spuncut Nybegynder
02. november 2004 - 08:18 #25
nååå...der manglede et M for Mega....
Avatar billede spuncut Nybegynder
02. november 2004 - 08:29 #26
Så kom vi ned på omkring 20ms for en "kendt" query....
Jeg skal lige teste din query..
Avatar billede spuncut Nybegynder
02. november 2004 - 08:41 #27
Din Query :

SELECT *, IF(Domain LIKE '%a%', 1, 0) +
          IF(Domain LIKE '%b%', 1, 0) +
          IF(Domain LIKE '%c%', 1, 0) AS score
FROM s_dk
HAVING score > 0
ORDER BY score DESC LIMIT 18880, 20

/* Result : "20 rows fetched ( 0,41 sec)" */

Min Query :

SELECT * FROM s_dk WHERE Domain LIKE '%a%'
    OR Domain LIKE '%b%'
    OR Domain LIKE '%c%'
    ORDER BY
    (IF(Domain LIKE '%a%', 1, 0) +
    IF(Domain LIKE '%b%', 1, 0) +
    IF(Domain LIKE '%c%', 1, 0))
    DESC LIMIT 18880, 20

/* Result : "20 rows fetched ( 0,34 sec)" */

Min er faktisk en smule hurtigere, men det har helt sikkert noget at gøre med hvor meget der bliver hentet.
Avatar billede majkat Nybegynder
02. november 2004 - 08:52 #28
Jeg er enig - i min udgave beregner MySQL score for hver eneste række i tabellen; i din sandsynligvis kun for de rækker der rent faktisk bliver udtrukket.

For et større resultatsæt er det mit gæt at

SELECT *, IF(Domain LIKE '%a%', 1, 0) AS score
FROM s_dk
HAVING score > 0
ORDER BY score DESC LIMIT 18880, 20

vil være en anelse hurtigere end

SELECT *
FROM s_dk
WHERE Domain LIKE '%a%'
ORDER BY IF(Domain LIKE '%a%', 1, 0) DESC LIMIT 18880, 20
Avatar billede spuncut Nybegynder
02. november 2004 - 08:53 #29
Ved 1000 rows:

Din query :


SELECT *, IF(Domain LIKE '%a%', 1, 0) +
IF(Domain LIKE '%b%', 1, 0) +
IF(Domain LIKE '%c%', 1, 0) AS score
FROM s_dk HAVING score > 0
ORDER BY score
DESC LIMIT 23000, 1000;

/* Result : "1000 rows fetched ( 0,44 sec)" */


Min Query :

SELECT * FROM s_dk WHERE Domain LIKE '%a%'
OR Domain LIKE '%b%'
OR Domain LIKE '%c%'
ORDER BY (IF(Domain LIKE '%a%', 1, 0) +
IF(Domain LIKE '%b%', 1, 0) +
IF(Domain LIKE '%c%', 1, 0))
DESC LIMIT 23000, 1000;


/* Result : "1000 rows fetched ( 0,39 sec)" */


Ikke den store forskel.....
Avatar billede majkat Nybegynder
02. november 2004 - 10:45 #30
Jeg mente nu ikke "mange rækker i LIMIT", men mange rækker der hvor MySQL skal beregne score for hver række den finder. Det var derfor min udgave kun begrænser på "a" og ikke "a" + "b" + "c". LIMIT skulle holdes konstant for sammenligning med de andre resultater.

Men spørgsmålet er, om forskellen overhovedet er målbar, jvfr. de resultater du allerede har vist - 0,05s kan vel ikke være meget mere end forskellen på at vente på at disken lige drejer sig en enkelt gang ekstra for at få læse/skrivehovedet frem til rette sted...
Avatar billede spuncut Nybegynder
02. november 2004 - 11:03 #31
Okææ.. Nej...gennemsnit af 10 affyringer
Resultat sæt  36189 records (hele tabellen)

SELECT *, IF(Domain LIKE '%s%', 1, 0) AS score
FROM s_dk HAVING score > 0 ORDER BY score DESC LIMIT 18880, 20;

/* Result : "20 rows fetched ( 0,33 sec)" */


SELECT * FROM s_dk
WHERE Domain LIKE '%s%'
ORDER BY IF(Domain LIKE '%s%', 1, 0) DESC LIMIT 18880, 20

* Result : "20 rows fetched ( 0,30 sec)" */
Avatar billede majkat Nybegynder
02. november 2004 - 11:17 #32
Damn.

Nå, så fik jeg også lært noget i dag, og det skal man jo aldrig være ked a' :-)

Tak for snakken - det var interessant.
Avatar billede spuncut Nybegynder
02. november 2004 - 11:37 #33
Tak for kompetent hjælp...
mht. tiderne absolut er det hvad man kan forvente af MySQL..??
Jeg bikser med at prøve det samme på min MSSQL, men jeg ved
ikke om jeg kan slå cache'n fra.
Avatar billede majkat Nybegynder
02. november 2004 - 12:07 #34
Du kan sikkert lave noget mere tuning, pille ved buffere osv. Men hvad du skal gøre herfra kommer helt an på scenariet (forventede mængder af data i produktionsudgaven, forventet antal samtidige brugere, hvilken hardware har du tilgængelig, osv)
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester