[PHP/(My)SQL] voor dummies #96

je kunt ook je query en je tabellen hier posten

Dit is de query. De tabel flightdb_flights laat zich raden. Voor de duidelijkheid heb ik de datatypes er even achter gezet. Deze heeft nu een index op (firstpilot_feu_id, secondpilot_feu_id), op (flighttime) en op (starttime). Er zitten nu een goeie 10.000 records in, ik reken op ongeveer 5000 records per jaar.

feusers_properties had ik al eens gepost, deze heb ik een index gegeven op (userid,title):

-edit-
een andere query die veel vaker voorkomt is dezelfde, maar dan eindigend op:
en ook:
waarbij de datum en userid uiteraard kunnen verschillen. Deze query's zijn allebei wel snel.

[ Bericht 10% gewijzigd door KomtTijd... op 14-11-2011 11:57:07 ]

Je berekent on the fly (huhu) waarden waarop je ordent, dat betekent min of meer dat er een volledige tijdelijke tabel opgebouwd moet worden (zou je waarschijnlijk ook zien in een query explain). Oftewel; bereken die flight-time voor en zet er een index op.

quote:

Op maandag 14 november 2011 11:56 schreef Catbert het volgende:
Je berekent on the fly (huhu) waarden waarop je ordent, dat betekent min of meer dat er een volledige tijdelijke tabel opgebouwd moet worden (zou je waarschijnlijk ook zien in een query explain). Oftewel; bereken die flight-time voor en zet er een index op.

Dat is juist wat ik gedaan heb. Flighttime is nu een eigen kolom met index, terwijl deze eerst met TIMEDIFF on the fly berekend werd. Het verschil in prestaties is alleen marginaal.

Ik heb ook geprobeerd wat het verschil is tussen WHERE YEAR(starttime) = '2011' en WHERE starttime BETWEEN 2011-01-01 AND 2011-12-31, maar dat is ook nihil/onmeetbaar.

Doe eens een query explain?

Sowieso is een query op 10k records complete peanuts.

quote:

Op maandag 14 november 2011 12:03 schreef Catbert het volgende:
Doe eens een query explain?

ik zit me nog even in te lezen hoe ik dit moet vertalen...

-edit- _{voor de scherpe lezers: in de testdatabase stond dus ook nog een index op airplane.}
Ik heb een index gemaakt op (airplane,starttime,flighttime), dat kan maar dan gebruikt 'ie nog steeds liever de index op flighttime.

quote:

Sowieso is een query op 10k records complete peanuts.

Dat leek mij ook, daarom is het ook irritant dat het zo traag gaat.

[ Bericht 1% gewijzigd door KomtTijd... op 14-11-2011 12:37:58 ]

Waar is die explain van en kan je dat niet mooier weergeven?

>> De tabel flightdb_flights laat zich raden.
niet waar, bovendien zijn er meer tabellen

>> AND airplane IN ('PH454','PH974','PH1006','PH1210','PH1382','PH1417','PH1433')
hoe selectief is dat?

Ik snap echt niet waarom MySQL een tijdelijke tabel nodig denkt te hebben hiervoor. Rare query explain trouwens, probeer eens "EXPLAIN EXTENDED"?

Ben wel blij dat we hier vooral met MSSQL werken zeg...

quote:

Op maandag 14 november 2011 12:20 schreef KomtTijd... het volgende:
Dat leek mij ook, daarom is het ook irritant dat het zo traag gaat.

Nou waarom het zo traag gaat is wel duidelijk. De vraag is waarom hij voor dat execution plan kiest...

Ah, ik heb gevonden wat het verschil maakt! De index op (userid,data) in de tabel feusers_properties! Dan valt ook ineens de "Using temporary; Using filesort" weg uit de explain.
Ik heb nu WHERE (flighttime > 01:05:00) weer uit de query gehaald, met index duurt de query nu rond de 0,006 seconden, zonder nog steeds 7-8 seconden.

Helaas probeer ik dat nu pas zónder die WHERE (flighttime > 01:05:00), waardoor het me nog niet opgevallen was. Ik was gisteren de boel al online aan het zetten (en had dus de benchmarks weggehaald).

quote:

Op maandag 14 november 2011 12:52 schreef GlowMouse het volgende:
Waar is die explain van en kan je dat niet mooier weergeven?

>> De tabel flightdb_flights laat zich raden.
niet waar, bovendien zijn er meer tabellen

de explain is van de query exact zoals ik hierboven gepost heb (dus niet die twee varianten). Mooier weergeven zou kunnen maar ik wist/weet amper waar ik naar zit te kijken. Heb exlpain nog niet eerder gebruikt.
Wat zou je nog meer willen weten over flightdb_flights? En meer tabellen... Ja die zijn er, maar zitten niet in deze query. Moet ik dan mijn hele database posten? Lijkt me een beetje overdreven...
dit is écht de hele tabel dan.
En dit de hele tabel feusers_properties

quote:

>> AND airplane IN ('PH454','PH974','PH1006','PH1210','PH1382','PH1417','PH1433')
hoe selectief is dat?

Niet bepaald, denk dat je dan nog 90% over hebt.

quote:

Op maandag 14 november 2011 13:01 schreef Catbert het volgende:

[..]

Nou waarom het zo traag gaat is wel duidelijk. De vraag is waarom hij voor dat execution plan kiest...

Je hebt het hier dus over "using temporary", neem ik aan?
Dan weet ik dat ik dat voortaan in de gaten moet houden.

quote:

Op maandag 14 november 2011 13:28 schreef KomtTijd... het volgende:
Je hebt het hier dus over "using temporary", neem ik aan?
Dan weet ik dat ik dat voortaan in de gaten moet houden.

Using temporary en using filesort zijn beiden indicaties dat MySQL het niet op de indexen op heeft kunnen lossen en zijn flinke performance hits.

Voor de volgende keer: blijf testen met die simpele query een paar posts terug. Je zet ons ook op het verkeerde been door over te stappen op die grote join.

Mja om het echt goed uit te zoeken had ik gewoon een testcase moeten maken inderdaad.
Zo zie je maar weer, systematisch aanpakken gaat toch altijd weer het snelst.

SHOW CREATE TABLE laat ook je indices zien.

Ik snap er echt geen donder van.

ik heb een script dat werk verdeeld, dit script include een rapportage script.
Wanneer het werk script word gedraaid schrijft het rapportage script netjes alle informatie weg in een log directory en zend een mail.
Savonds word ditzelfde script gestart door een scheduled task op een windows 2008 server....
Maar daar gaat het fout, deze geeft aan dat hij gedraaid heeft maar mn logs worden niet weggeschreven.
Start ik de task met de hand dan word alles netjes weggeschreven

Nu heb ik een kopie van de task gemaakt en een kopie van het rapportage script.
Enkel de log directory heb ik veranderd, deze zend netjes de mail uit en schrijft de logs weg?

Enige wat ik nog niet geprobeerd heb ik dezelfde logdir aanhouden, maar dat zou niet uit moeten maken aangezien sochtends alles wel word weg geschreven.

Ander leuk feit toen dit nog op een unix machine draaide was er geen enkel probleem.

db: naam, ww encrypted met md5. bij inloggen wordt het wachtwoord omgezet naar md5 voor naar de server gestuurd te worden. cookie met naam en md5-ww staat in cookie om ingelogd te blijven.

De vraag is of dit een veilige methode is, heb verder totaal geen ervaring met beveiliging/inloggen met php.

voordelen:
- ww staat niet open en bloot in cookie.
- ww wordt encrypted over het internet verstuurd
- bij serverhack staan user-ww'en niet openbaar

nadelen:
- cookies?

quote:

Op dinsdag 15 november 2011 09:23 schreef n8n het volgende:
db: naam, ww encrypted met md5. bij inloggen wordt het wachtwoord omgezet naar md5 voor naar de server gestuurd te worden. cookie met naam en md5-ww staat in cookie om ingelogd te blijven.

De vraag is of dit een veilige methode is, heb verder totaal geen ervaring met beveiliging/inloggen met php.

voordelen:
- ww staat niet open en bloot in cookie.
- ww wordt encrypted over het internet verstuurd
- bij serverhack staan user-ww'en niet openbaar

nadelen:
- cookies?

Je kunt ook gewoon bij het inloggen controleren of de opgegeven username en het wachtwoord overeen komen met een match in de database en met elkaar. Dan hoef je helemaal geen cookies te gebruiken. Weet overigens niet of dit beter is hoor.

quote:

Op dinsdag 15 november 2011 09:23 schreef n8n het volgende:
db: naam, ww encrypted met md5. bij inloggen wordt het wachtwoord omgezet naar md5 voor naar de server gestuurd te worden. cookie met naam en md5-ww staat in cookie om ingelogd te blijven.

De vraag is of dit een veilige methode is, heb verder totaal geen ervaring met beveiliging/inloggen met php.

voordelen:
- ww staat niet open en bloot in cookie.
- ww wordt encrypted over het internet verstuurd
- bij serverhack staan user-ww'en niet openbaar

nadelen:
- cookies?

MD5 is imo een beetje verouderd, simpele wachtwoorden zijn eenvoudig te achterhalen. Ik zou bijvoorbeeld SHA gebruiken.
Om ingelogd te blijven zou ik een random hash in een cookie zetten die je aan de user koppelt.

quote:

Op dinsdag 15 november 2011 09:05 schreef Darkomen het volgende:
Ik snap er echt geen donder van.

ik heb een script dat werk verdeeld, dit script include een rapportage script.
Wanneer het werk script word gedraaid schrijft het rapportage script netjes alle informatie weg in een log directory en zend een mail.
Savonds word ditzelfde script gestart door een scheduled task op een windows 2008 server....
Maar daar gaat het fout, deze geeft aan dat hij gedraaid heeft maar mn logs worden niet weggeschreven.
Start ik de task met de hand dan word alles netjes weggeschreven

Nu heb ik een kopie van de task gemaakt en een kopie van het rapportage script.
Enkel de log directory heb ik veranderd, deze zend netjes de mail uit en schrijft de logs weg?

Enige wat ik nog niet geprobeerd heb ik dezelfde logdir aanhouden, maar dat zou niet uit moeten maken aangezien sochtends alles wel word weg geschreven.

Ander leuk feit toen dit nog op een unix machine draaide was er geen enkel probleem.

Vanuit welke user stuur je hem handmatig aan en vanuit welke user via de scheduled task?

Zou beide de zelfde user moeten zijn, maar moet ook niet uitmaken, de 2de windows task draait namelijk wel.

quote:

Op dinsdag 15 november 2011 09:05 schreef Darkomen het volgende:
Ik snap er echt geen donder van.

ik heb een script dat werk verdeeld, dit script include een rapportage script.
Wanneer het werk script word gedraaid schrijft het rapportage script netjes alle informatie weg in een log directory en zend een mail.
Savonds word ditzelfde script gestart door een scheduled task op een windows 2008 server....
Maar daar gaat het fout, deze geeft aan dat hij gedraaid heeft maar mn logs worden niet weggeschreven.
Start ik de task met de hand dan word alles netjes weggeschreven

Nu heb ik een kopie van de task gemaakt en een kopie van het rapportage script.
Enkel de log directory heb ik veranderd, deze zend netjes de mail uit en schrijft de logs weg?

Enige wat ik nog niet geprobeerd heb ik dezelfde logdir aanhouden, maar dat zou niet uit moeten maken aangezien sochtends alles wel word weg geschreven.

Ander leuk feit toen dit nog op een unix machine draaide was er geen enkel probleem.

Rechtenprobleem op de map ivm taak scheduler en account waaronder deze draait.

Hoe moet ik dat dan zien?
Via het script => http / iis user
Windows tasks => de ingelogde user

Als ik de rechten check hebben zowel de user als iis dezelfde rechten op de map.

quote:

Op dinsdag 15 november 2011 09:23 schreef n8n het volgende:
db: naam, ww encrypted met md5. bij inloggen wordt het wachtwoord omgezet naar md5 voor naar de server gestuurd te worden. cookie met naam en md5-ww staat in cookie om ingelogd te blijven.

De vraag is of dit een veilige methode is, heb verder totaal geen ervaring met beveiliging/inloggen met php.

voordelen:
- ww staat niet open en bloot in cookie.
- ww wordt encrypted over het internet verstuurd
- bij serverhack staan user-ww'en niet openbaar

nadelen:
- cookies?

Je zet ten eerste nooit een PW uberhaupt in een cookie. Je onthoudt de sessie. Daarnaast is MD5 achterhaald. Tenslotte zie ik nergens salts genoemd en ik hoop niet dat je overweegt MD5 passwords unsalted in je DB op te slaan?

Ok duidelijk, dan heb ik weer iets om me over in te lezen. bedankt

quote:

Op dinsdag 15 november 2011 09:25 schreef boem-dikkie het volgende:

[..]

Je kunt ook gewoon bij het inloggen controleren of de opgegeven username en het wachtwoord overeen komen met een match in de database en met elkaar. Dan hoef je helemaal geen cookies te gebruiken. Weet overigens niet of dit beter is hoor.

dat doe ik ook wel, had alleen geen idee hoe ik een sessie aan kon maken

Eeuhm... Admin vragen op de server perhaps denk ik nu