DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Ja, als ik de GROUP BY aanpas naar bv a.title is hij de eerste keer weer traag.quote:Op vrijdag 3 maart 2006 14:31 schreef JeRa het volgende:
[..]
Dit is een mooi voorbeeld van een query die géén indices gebruikt maar de tweede keer snel wordt door het gebruik van de query cache op de server. Ik zie zo even niet waarom hij ze niet gebruikt.
Als het goed is zou je door iets te veranderen in één van de tabellen de query uit de query cache kunnen halen, is hij dan weer zo traag?
Ik vreesde ook al dat de query daadwerkelijk traag is en de tweede keer uit cache komt
ongeveer 2000 records in de ad table, 19 in de genre tabel en een stuk of 100 in de user tabel. ALlemaal niet erg spannendquote:Op vrijdag 3 maart 2006 14:48 schreef Scorpie het volgende:
Hm ik zie zo 1,2,3 niet in waarom hij zo lang moet laden...heel apart. Hoeveel data bevatten de tabellen?
Om voor testing purposes de query cache eventjes te omzeilen zou je SQL_NO_CACHE kunnen gebruiken, zie deze pagina.quote:Op vrijdag 3 maart 2006 14:49 schreef Swetsenegger het volgende:
[..]
Ja, als ik de GROUP BY aanpas naar bv a.title is hij de eerste keer weer traag.
Ik vreesde ook al dat de query daadwerkelijk traag is en de tweede keer uit cache komt
Je GROUP BY is trouwens niet helemaal goed. Alle velden die je in de SELECT gebruikt en die je niet in een aggregate functie hebt staan, moeten in de GROUP BY worden opgenomen. MySQL accepteerd het wel als je dat niet doet, maar dat kan tot onvoorspelbare resultaten leiden. Zo zou het moeten:quote:Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:
[..]
De Query?
[ code verwijderd ]
-edit-
indices op a.ad_id (PK), a.genre, g.genre_id (PK)
| 1 |
Eventueel zou je alleen de PK's op kunnen nemen. Dan zijn de resultaten voorspelbaar maar misschien is het ietsje sneller
| 1 |
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
De aggregate functie is... het optel gebeuren?quote:Op vrijdag 3 maart 2006 15:40 schreef SuperRembo het volgende:
[..]
Je GROUP BY is trouwens niet helemaal goed. Alle velden die je in de SELECT gebruikt en die je niet in een aggregate functie hebt staan, moeten in de GROUP BY worden opgenomen. MySQL accepteerd het wel als je dat niet doet, maar dat kan tot onvoorspelbare resultaten leiden. Zo zou het moeten:
[ code verwijderd ]
Eventueel zou je alleen de PK's op kunnen nemen. Dan zijn de resultaten voorspelbaar maar misschien is het ietsje sneller
[ code verwijderd ]
Inderdaad gaf hij af en toe onvoorspelbare resultaten met a.title in de GROUP BY, met a.ad_id lijkt dat verholpen Maar als ik de query een beetje volg lijkt hij me niet ZO traag toch? 15 seconden vind ik wel overdreven lang.
Ik weet niet in welke volgorde MySQL die joins uitvoert. Met een beetje pech begint MySQL met de join van ad op ad. Die geeft 2000 * 2000 / 2 = 2000000 rows.
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Zelfs dan zou het niet zó lang mogen duren, toch? Een query op een tabel met 10.000 rows die ik op zichzelf laat joinen is in een fractie van een seconde gedaan.
Als ik via de post-method van een form iets meegeef, dan hoor ik die variabele op de 'volgende' pagina toch direct uitlezen met $variabele? Ik kan me herinneren dat ik dit altijd deed, maar nu ik de boel lokaal aan het maken ben, werkt dat niet. Ik moet dan de meegegeven variabele eerst uitlezen:
$variabele = $_POST['bla'];
En ik kan dus niet direct $bla gebruiken...Is het iets in de php.ini wat ik moet veranderen?
$variabele = $_POST['bla'];
En ik kan dus niet direct $bla gebruiken...Is het iets in de php.ini wat ik moet veranderen?
*BURP*
Ja. Maar je kan beter altijd $_POST en $_GET gebruiken. Vooral met POST, anders kunnen mensen iets in de URL veranderen en dan wordt dat gewoon geaccepteerd.
register_globals
register_globals
GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!
Hier begrijp ik niets van.quote:Op vrijdag 3 maart 2006 17:23 schreef SuperRembo het volgende:
Ik weet niet in welke volgorde MySQL die joins uitvoert. Met een beetje pech begint MySQL met de join van ad op ad. Die geeft 2000 * 2000 / 2 = 2000000 rows.
Ik zie de eerste rij in de tabel, die heeft genre id 1.
Dan begint hij weer van bovenaf aan, alles negerend totdat hij er weer 1 tegenkomt met genre id 1. En weer bovenaan, tot hij een derde heeft gevonden met genre id 1.
En zo voor alle genre's welke beschikbaar zijn in de genre tabel. Zeg ik het zo correct?
Dan loopt hij toch door maximaal 19(genres)*3(max resultaten per genre)*2000(advertenties)= 114.000 rijen?
Maar is er sowieso een manier om dit effectiever te doen?
Dat dacht ik ook.quote:Op vrijdag 3 maart 2006 18:06 schreef JeRa het volgende:
Zelfs dan zou het niet zó lang mogen duren, toch? Een query op een tabel met 10.000 rows die ik op zichzelf laat joinen is in een fractie van een seconde gedaan.
Hmz, de hele database geexporteerd en lokaal geimporteerd.
de query duurt ruim 9 seconden
-edit-
Een simpel
duurt 0.0004 seconden.
Snel rekensommetje leert dat
19*0.0004=0.0076 seconden duurt. Daar zal nog wel wat overhead vanaf vallen, maar ik denk dat het toch minimaal een factor 100 sneller is.
Het gadverdamme ik haat een frontpage waarop 20 queries gedraaid worden. Ik vond SuperRembo's oplossing juist zo'n geile query
-edit 2-
Subqueries worden pas vanaf MySQL 5 ondersteunt toch?
[ Bericht 49% gewijzigd door Swetsenegger op 03-03-2006 20:20:26 ]
de query duurt ruim 9 seconden
-edit-
Een simpel
| 1 2 3 4 5 | FROM ad WHERE genre=1 ORDER BY ad_id DESC LIMIT 3 |
duurt 0.0004 seconden.
Snel rekensommetje leert dat
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $queryMain="SELECT * FROM genre"; $resultMain=mysql_query($queryMain); while($rowMain=mysql_fetch_assoc($resultMain)){ $querySub="SELECT title, ad_id, image, price FROM ad WHERE genre=".$rowMain['genre_id']." ORDER BY ad_id DESC LIMIT 3"; $resultSub=mysql_query($querySub); while($rowSub=mysql_fetch_assoc($resultSub)){ // doe iets } } ?> |
19*0.0004=0.0076 seconden duurt. Daar zal nog wel wat overhead vanaf vallen, maar ik denk dat het toch minimaal een factor 100 sneller is.
Het gadverdamme ik haat een frontpage waarop 20 queries gedraaid worden. Ik vond SuperRembo's oplossing juist zo'n geile query
-edit 2-
Subqueries worden pas vanaf MySQL 5 ondersteunt toch?
[ Bericht 49% gewijzigd door Swetsenegger op 03-03-2006 20:20:26 ]
Ik moet toe geven dat het stiekum toch een draak van een query is. Ik heb ff een testje gedraaid met een tabel met 10000 rows... daarmee legde MySQL m'n pc 16 minuten plat. MSSQL deed het met dezelfde data in 42 seconden.quote:Op vrijdag 3 maart 2006 19:28 schreef Swetsenegger het volgende:
Het gadverdamme ik haat een frontpage waarop 20 queries gedraaid worden. Ik vond SuperRembo's oplossing juist zo'n geile query
Wil iedereen die in telekinese gelooft nu mijn hand op steken?
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
| Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
Maar hij zag er wel heel cool uit en LIJKT veel sneller dan 20 queriesquote:Op vrijdag 3 maart 2006 21:18 schreef SuperRembo het volgende:
[..]
Ik moet toe geven dat het stiekum toch een draak van een query is. Ik heb ff een testje gedraaid met een tabel met 10000 rows... daarmee legde MySQL m'n pc 16 minuten plat. MSSQL deed het met dezelfde data in 42 seconden.
Verrassend trouwens dat MSSQL zoveel sneller is. Toevallig heb ik van de week een intranet applicatie van MySQL naar MSSQL gemigreerd.
En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.quote:Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:
[..]
De Query?
[ code verwijderd ]
-edit-
indices op a.ad_id (PK), a.genre, g.genre_id (PK)
Of ik begrijp dat explain gewoon niet, of ik doe wat fout.quote:Op vrijdag 3 maart 2006 21:34 schreef Light het volgende:
[..]
En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.
Anyway, dit komt eruit
| 1 2 3 4 | g ALL PRIMARY NULL NULL NULL 19 Using temporary; Using filesort a ref PRIMARY,genre genre 4 g.genre_id 24 Using where a2 ref PRIMARY,genre genre 4 g.genre_id 24 Using where |
In een bericht wat ik via de php mail() functie stuur, zitten newlines (dus \n ). Dit zou gewoon een enter moeten geven, maar in het mailtje geeft ie gewoon letterlijk \n weer. Hij pakt in normale pagina's \n ook niet, dus volgens mij werken die escape characters niet. Ik dacht dat dit lag aan magic_quotes_gpc. Deze stond bij mij op Off, maar als ik 'm aanzet werkt 't alsnog niet... Is er iets anders wat ik moet veranderen?
*BURP*
De geescapede newlines (\n) werken over het algemeen alleen als je ze in een string zet met dubbele quotes (aanhalingstekens) eromheen, dus "\n" of "blaat\nblaat". Heb je ze toevallig in single quoted strings gezet? ( '\n' )
Hij is lastigquote:Op vrijdag 3 maart 2006 21:57 schreef Swetsenegger het volgende:
[..]
Of ik begrijp dat explain gewoon niet, of ik doe wat fout.
Anyway, dit komt eruit
[ code verwijderd ]
Maar als je nou de key genre in de tabel ad eens aanpast er daar ad_id als tweede index bij zet, wordt het dan sneller?
MySQL heeft de leuke eigenschap dat het maar 1 key (index dus) kan gebruiken.
quote:Op zaterdag 4 maart 2006 10:49 schreef Light het volgende:
[..]
Hij is lastig
Maar als je nou de key genre in de tabel ad eens aanpast er daar ad_id als tweede index bij zet, wordt het dan sneller?
MySQL heeft de leuke eigenschap dat het maar 1 key (index dus) kan gebruiken.
ad_id is de PK, die is toch al index?
Ja, ik bedoelde dan ook een index op meerdere kolommen, namelijk genre en ad_id.quote:Op zaterdag 4 maart 2006 11:04 schreef Swetsenegger het volgende:
[..]
ad_id is de PK, die is toch al index?
dus de index op genre zou het juist trager maken ipv sneller?quote:Op zaterdag 4 maart 2006 11:14 schreef Light het volgende:
[..]
Ja, ik bedoelde dan ook een index op meerdere kolommen, namelijk genre en ad_id.
Ik bedoelde dus een index op (genre, ad_id). Maar je zou ook de index op genre eens weg kunnen halen om te kijken of dat effect heeft. Ik vermoed dat het wel merkbaar is, omdat er dan een index gebruikt kan worden bij de group by. Lijkt mij.quote:Op zaterdag 4 maart 2006 11:32 schreef Swetsenegger het volgende:
[..]
dus de index op genre zou het juist trager maken ipv sneller?
Ah zoquote:Op zaterdag 4 maart 2006 11:38 schreef Light het volgende:
[..]
Ik bedoelde dus een index op (genre, ad_id). Maar je zou ook de index op genre eens weg kunnen halen om te kijken of dat effect heeft. Ik vermoed dat het wel merkbaar is, omdat er dan een index gebruikt kan worden bij de group by. Lijkt mij.
Nee, dat heeft geen effect want ik ben juist met indexes gaan klooien omdat die query zo traag was
Ik heb nu dus die query herschreven zoals op de vorige pagina, en ondanks dat ik dus 20 queries draai, vliegt dit het scherm op.
Mooi is het niet, effectief wel. Daarom vroeg ik al vanaf welke MySQL versie subqueries ondersteunt worden (4.1) maar er draait 4.0 op de server.
Speciaal voor Tijn trouwens, kon je deze al?:
http://www.apple.com/downloads/macosx/unix_open_source/mamp.html
Ik ga denk ik ook maar zoeken naar een xserve
Als ik hier lokaal ga testen dan is die query nog best snel. Maar ik heb natuurlijk geeen 2000 rows in een ad tabelquote:Op zaterdag 4 maart 2006 12:14 schreef Swetsenegger het volgende:
[..]
Ah zo
Nee, dat heeft geen effect want ik ben juist met indexes gaan klooien omdat die query zo traag was
Ik heb nu dus die query herschreven zoals op de vorige pagina, en ondanks dat ik dus 20 queries draai, vliegt dit het scherm op.
Mooi is het niet, effectief wel. Daarom vroeg ik al vanaf welke MySQL versie subqueries ondersteunt worden (4.1) maar er draait 4.0 op de server.
