[PHP/(My)SQL] voor dummies - Deel 22 | Digital Corner (DIG)

FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 22:05:08 #241

Swetsenegger

Egocentrische Narcist

quote:
Op donderdag 2 maart 2006 21:55 schreef JeRa het volgende:

[..]

Niet bij álle foreign keys, maar het is een goede vuistregel ja. Voorbeeldje waarbij het niet moet; als je voor een fotoalbum drie groottes van een bepaalde foto hebt kun je die drie groottes in één record laten verwijzen naar drie foreign records, maar daar hoeft in principe helemaal geen index op omdat je daar nooit op selecteert of sorteert.

Nee ok, alleen op kolommen waarop je selecteert of sorteert is een betere benaming.

quote:
In álle gevallen worden INSERTs trager door indices, en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of niet dus wat dat betreft zal het niet trager worden.

Van mysql.org:
If you need to access most of the rows, it is faster to read sequentially, because this minimizes disk seeks.

Maar ja, in bovenstaand voorbeeld heb ik regelmatig ALLE product rows nodig. Zijn indexes dan aan te raden of niet?

 | FOK! Schrikkelbaasch

donderdag 2 maart 2006 @ 22:10:40 #242

SuperRembo

Sinds 1998

quote:
Op donderdag 2 maart 2006 21:55 schreef JeRa het volgende:
en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of niet

MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.

donderdag 2 maart 2006 @ 23:14:06 #243

JeRa

quote:
Op donderdag 2 maart 2006 22:05 schreef Swetsenegger het volgende:
Maar ja, in bovenstaand voorbeeld heb ik regelmatig ALLE product rows nodig. Zijn indexes dan aan te raden of niet?

In jouw voorbeeld zie ik één query die alle rows aandoet en die sorteert op first_price; die zou je prima kunnen indexeren.

quote:
Op donderdag 2 maart 2006 22:10 schreef SuperRembo het volgende:

[..]

MySQL staat nou niet echt goed bekend om z'n query optimalisatie kwaliteiten.

Dat weet ik, ik ga er altijd vanuit dat ze dat in de toekomst nog kunnen verbeteren terwijl de queries hetzelfde blijven. Als het een probleem wordt schakel ik over op een andere DBMS die dat wel kan bepalen

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 08:57:08 #244

Swetsenegger

Egocentrische Narcist

quote:
Op donderdag 2 maart 2006 23:14 schreef JeRa het volgende:

[..]

In jouw voorbeeld zie ik één query die alle rows aandoet en die sorteert op first_price; die zou je prima kunnen indexeren.
[..]

Dat weet ik, ik ga er altijd vanuit dat ze dat in de toekomst nog kunnen verbeteren terwijl de queries hetzelfde blijven. Als het een probleem wordt schakel ik over op een andere DBMS die dat wel kan bepalen

First price heb ik inderdaad nu geindexeerd.
Ik doelde ook op de foreign keys in de andere tabellen. DIe worden mondjes maat in joins gebruikt. Maar in mijn beleving zijn joins zware queries, dus wil ik het maar optimaliseren

Bedankt weer voor de uitleg

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 11:04:18 #245

Swetsenegger

Egocentrische Narcist

Ik heb een mooie query van Super Rembo, welke 3 laatste records per catagorie uit de database trekt.
Alleen duurt deze query tussen de 15(!) en 0.0003 seconden. De eerste keer doet hij er meestal heel lang over, de tweede keer korter.

Ik mag toch aannemen dat dat aan de hoster ligt?

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 11:13:37 #247

Swetsenegger

Egocentrische Narcist

quote:
Op vrijdag 3 maart 2006 11:08 schreef Scorpie het volgende:

[..]

Laat eens zien?

De Query?

1
2
3
4
5
6
7

SELECT g.genre, g.genre_id, a.title, a.ad_id, a.image, a.price
FROM genre g
INNER JOIN ad a ON a.genre = g.genre_id
INNER JOIN ad a2 ON a2.genre = g.genre_id AND a.ad_id <= a2.ad_id
GROUP BY a.ad_id
HAVING COUNT(a2.ad_id) <= 3
ORDER BY g.genre_id, a.ad_id DESC

-edit-
indices op a.ad_id (PK), a.genre, g.genre_id (PK)

 | FOK! Schrikkelbaasch

vrijdag 3 maart 2006 @ 11:14:27 #248

Nevermind

(-_-)

quote:
Op vrijdag 3 maart 2006 11:13 schreef Swetsenegger het volgende:

[..]

De Query?

Wat anders?

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

vrijdag 3 maart 2006 @ 14:31:17 #249

JeRa

quote:
Op vrijdag 3 maart 2006 11:04 schreef Swetsenegger het volgende:
Alleen duurt deze query tussen de 15(!) en 0.0003 seconden. De eerste keer doet hij er meestal heel lang over, de tweede keer korter.

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?

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 14:49:15 #251

Swetsenegger

Egocentrische Narcist

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?

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

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 14:49:58 #252

Swetsenegger

Egocentrische Narcist

quote:
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?

ongeveer 2000 records in de ad table, 19 in de genre tabel en een stuk of 100 in de user tabel. ALlemaal niet erg spannend

 | FOK! Schrikkelbaasch

vrijdag 3 maart 2006 @ 15:13:30 #253

JeRa

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

Om voor testing purposes de query cache eventjes te omzeilen zou je SQL_NO_CACHE kunnen gebruiken, zie deze pagina.

vrijdag 3 maart 2006 @ 15:40:17 #254

SuperRembo

Sinds 1998

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)

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:

1	GROUP BY g.genre, g.genre_id, a.title, a.ad_id, a.image, a.price

Eventueel zou je alleen de PK's op kunnen nemen. Dan zijn de resultaten voorspelbaar maar misschien is het ietsje sneller

1	GROUP BY g.genre_id, a.ad_id

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 16:27:40 #255

Swetsenegger

Egocentrische Narcist

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 ]

De aggregate functie is... het optel gebeuren?

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.

 | FOK! Schrikkelbaasch

vrijdag 3 maart 2006 @ 17:23:38 #256

SuperRembo

Sinds 1998

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.

vrijdag 3 maart 2006 @ 18:06:04 #257

JeRa

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.

vrijdag 3 maart 2006 @ 18:44:01 #258

H4ze

wait...what?

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?

*BURP*

vrijdag 3 maart 2006 @ 18:45:42 #259

Nevermind

(-_-)

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}

GTA San Andreas Multiplayer: Las Venturas Playground Doe mee met FOK! Whatpulse en typ FOK! naar de 1e plaats!!

vrijdag 3 maart 2006 @ 18:46:51 #260

R-Mon

jong en dynamisch

En anders extract.

<tsjsieb> maarja, jij bent ook gewoon cool R-Mon :p

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 19:15:50 #261

Swetsenegger

Egocentrische Narcist

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.

Hier begrijp ik niets van.
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?

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.

Dat dacht ik ook.

 | FOK! Schrikkelbaasch

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 19:28:53 #262

Swetsenegger

Egocentrische Narcist

Hmz, de hele database geexporteerd en lokaal geimporteerd.
de query duurt ruim 9 seconden

-edit-
Een simpel

1
2
3
4
5

SELECT title, ad_id, image, price
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

<?php
$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 ]

 | FOK! Schrikkelbaasch

vrijdag 3 maart 2006 @ 21:18:19 #263

SuperRembo

Sinds 1998

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

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.

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 21:22:14 #264

Swetsenegger

Egocentrische Narcist

quote:
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.

Maar hij zag er wel heel cool uit en LIJKT veel sneller dan 20 queries

Verrassend trouwens dat MSSQL zoveel sneller is. Toevallig heb ik van de week een intranet applicatie van MySQL naar MSSQL gemigreerd.

 | FOK! Schrikkelbaasch

vrijdag 3 maart 2006 @ 21:34:22 #265

Light

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)

En wat geeft de EXPLAIN van die query? Dat levert meestal wel info waarmee je kunt kijken wat er lang duurt.

fokstok.nl

FOK!-Schrikkelbaas vrijdag 3 maart 2006 @ 21:57:41 #266

Swetsenegger

Egocentrische Narcist

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.

Of ik begrijp dat explain gewoon niet, of ik doe wat fout.
Anyway, dit komt eruit

1
2
3
4

table      type      possible_keys      key      key_len      ref           rows      Extra
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

 | FOK! Schrikkelbaasch

zaterdag 4 maart 2006 @ 02:48:18 #267

H4ze

wait...what?

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*

zaterdag 4 maart 2006 @ 06:44:40 #268

JeRa

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' )

zaterdag 4 maart 2006 @ 10:49:20 #269

Light

quote:
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 ]

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.

fokstok.nl

FOK!-Schrikkelbaas zaterdag 4 maart 2006 @ 11:04:02 #270

Swetsenegger

Egocentrische Narcist

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?

 | FOK! Schrikkelbaasch

Forum Opties
Forumhop:
Hop naar:	(afkorting, bv 'KLB')

[PHP/(My)SQL] voor dummies - Deel 22

» digital corner

» digital corner