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.
Het gaat om mijn statistieken script waarbij ik gemiddeld zó'n 15 queries per load, ik heb werkelijk waar geen idee hoe ik dit zou moeten cachen!quote:Op zaterdag 22 november 2008 11:46 schreef GlowMouse het volgende:
Als je tijdens traagheid geen queries in SHOW FULL PROCESSLIST ziet, dan worden er op dat moment geen queries uitgevoerd. Dat wijst erop dat je gewoon teveel queries doet die wel allemaal heel snel uitgevoerd kunnen worden. Als je ook al praat over 'een berg met queries' dan kan ik wel raden wat er fout gaat. Als iemand een pagina opvraagt, moet je gewoon zorgen dat je met zo min mogelijk en goed geïndexeerde queries toekunt.
Leek mij idd ook nietquote:De slowquerylog heeft met veel maar korte queries ook niet zoveel zin.
Had ik reeds gedaan maar kon er niet echt wijs uit wordenquote:Bij SHOW STATUS is er heel veel waar je op moet letten. Beste is om de handleiding ernaast te houden en iedere waarde te controleren en te kijken of dat een oorzaak kan zijn van traagheid. Dat kan sowieso geen kwaad als je meer van MySQL wilt weten
Jawel, een hele berg zelfs! maar hoezo?quote:
Dus je hebt er geen unieke sleutels inzitten?
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Je had het over een berg; 15 is niets. Je zult wel geen of slechte indexen hebben staan. Geef maar wat queries, hun EXPLAIN output, en je hele table lay-out (incl geplaatste indices).quote:
[..]
Het gaat om mijn statistieken script waarbij ik gemiddeld zó'n 15 queries per load, ik heb werkelijk waar geen idee hoe ik dit zou moeten cachen!
[ Bericht 0% gewijzigd door GlowMouse op 22-11-2008 15:13:14 ]
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Klinkt alsof je veel samengestelde queries gebruikt, en dan kan het maken van indexes op je primaire/vreemde sleutels wel eens heeeel erg veel tijd schelen bij samengestelde queriesquote:Op zaterdag 22 november 2008 13:48 schreef Chandler het volgende:
Jawel, een hele berg zelfs! maar hoezo?
Mag ik dit ook per PM doen, aangezien ik niet mijn hele structuur op het internet beschikbaar wil hebbenquote:
Je had het over een berg; 15 is niets. Je zult wel geen of slechte indexen hebben staan. Geef maar wat queries, hun EXPLAIN output, en je hele table lay-out (incl geplaatste indices).
The people who lost my respect will never get a capital letter for their name again.
Like trump...
Like trump...
Ja primaje postcount!
[ Bericht 60% gewijzigd door GlowMouse op 22-11-2008 16:32:18 ]
[ Bericht 60% gewijzigd door GlowMouse op 22-11-2008 16:32:18 ]
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
commentator: zie UNION, maar bedenk dat het je geen betere performance oplevert en overzichtelijkheid in veel gevallen ook ver te zoeken is.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
De tabellen vak en resultaat is dan alles wat je nodig hebt.quote:
De bedoeling is nu dat ik voor de vakken hardware en systeemontwikkeling per vak het gemiddelde cijfer geef.
| 1 2 3 4 | FROM vak JOIN resultaat AS res ON res.vak=vak.code GROUP BY vak.naam |
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Klein MySQL vraagje,
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Ik heb geprobeerd hem te resetten, maar niks hielp. Wel fixte een repair van die tabel het probleem. Maar mijn vraag is, hoe kan dit gebeuren? Dat de auto_increment value blijft hangen.
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Ik heb geprobeerd hem te resetten, maar niks hielp. Wel fixte een repair van die tabel het probleem. Maar mijn vraag is, hoe kan dit gebeuren? Dat de auto_increment value blijft hangen.
West Ham supporters, check: Dutchirons
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
dank je wel, ga ik bekijken.quote:Op zaterdag 22 november 2008 16:18 schreef GlowMouse het volgende:
commentator: zie UNION, maar bedenk dat het je geen betere performance oplevert en overzichtelijkheid in veel gevallen ook ver te zoeken is.
performance is niet van belang in dit geval. Het gaat er namelijk om om 1x per week snel een dump te kunnen maken van die twee gegevens. En dat is het prettiger als het in 1 query past dan in twee
<a href="http://whatpulse.org/ref/164249/" target="_blank" rel="nofollow">Typ mee, met FOK! naar de top</a>
Wat is het type van het veld waar de auto_increment op staat? Als dat bijvoorbeeld TINYINT is, dan is het logisch dat hij niet verder gaat: een TINYINT kan waarden aannemen van -128 tot 127. Dan zou je het type moeten aanpassen naar een groter datatype.quote:
Klein MySQL vraagje,
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Ik heb geprobeerd hem te resetten, maar niks hielp. Wel fixte een repair van die tabel het probleem. Maar mijn vraag is, hoe kan dit gebeuren? Dat de auto_increment value blijft hangen.
Uitleg over datatypen: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
Wat is sneller/beter/logischer?
Ik wil een UPDATE uitvoeren, echter wanneer de record nog niet bestaat moet het een INSERT zijn.
Dit kan op twee manieren:
- Met SELECT zoeken naar de record, indien deze bestaat een UPDATE uitvoeren, indien deze niet bestaat een INSERT.
- Met DELETE de record verwijderen, ongeacht of deze bestaat (dus zonder een SELECT) en vervolgend een INSERT.
Ik wil een UPDATE uitvoeren, echter wanneer de record nog niet bestaat moet het een INSERT zijn.
Dit kan op twee manieren:
- Met SELECT zoeken naar de record, indien deze bestaat een UPDATE uitvoeren, indien deze niet bestaat een INSERT.
- Met DELETE de record verwijderen, ongeacht of deze bestaat (dus zonder een SELECT) en vervolgend een INSERT.
ne okuyon, bokmu var?
Of altijd een insert proberen te doen en ON DUPLICATE KEY UPDATEquote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
Zoals hierboven ook al staat: je gebruikt een signed TINYINT datatype (unsigned gaat 'ie tot 255, dus voor auto_increments altijd unsigned gebruiken, dubbele capaciteit en je gaat toch nooit in het negatieve). Lekker INT van maken, kun je er (unsigned) 4294967295 kwijtquote:Op zondag 23 november 2008 11:19 schreef MrDoegewoon het volgende:
Klein MySQL vraagje,
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Thanks!quote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
ne okuyon, bokmu var?
Het verhaal van de signed tinyint verklaart niet waarom een REPAIR TABLE het probleem verhielp. Normaal gesproken zijn auto_increment kolommen heel betrouwbaar: zie de topicnummers/postnummers/userid's hier op FOK!, op GoT, en op vrijwel ieder ander forum.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Fout, REPLACE INTO verwijderd eerst het gevonden resultaat en INSERT INTO .. ON DUPLICATE KEY doet dat niet, deze past het resultaat alleen maar aan.quote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
Dus het is niet het enige juiste antwoord, maar een mogelijk antwoord.
Zie trouwens oon de opmerking over delete cascade in de docs: http://dev.mysql.com/doc/refman/5.0/en/replace.html
In theory there is no difference between theory and practice. In practice there is.
Gezien de vraag lijkt dat geen probleemquote:Op zondag 23 november 2008 15:10 schreef slacker_nl het volgende:
Fout, REPLACE INTO verwijderd eerst het gevonden resultaat en INSERT INTO .. ON DUPLICATE KEY doet dat niet, deze past het resultaat alleen maar aan.
Beide opties zijn overigens beter/sneller dan een select + update danwel delete + insert
Snap ik, maar vreemde is dat de counter pas op 52 hoorde te staan ipv 127.quote:Op zondag 23 november 2008 14:47 schreef CraZaay het volgende:
[..]
Zoals hierboven ook al staat: je gebruikt een signed TINYINT datatype (unsigned gaat 'ie tot 255, dus voor auto_increments altijd unsigned gebruiken, dubbele capaciteit en je gaat toch nooit in het negatieve). Lekker INT van maken, kun je er (unsigned) 4294967295 kwijt
West Ham supporters, check: Dutchirons
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
| 1 2 3 | <input type="checkbox" name="details" value="1" if($edit_details==1){ echo'checked="checked" disabled="disabled"';} /> ?> |
Waarom is na de submit $_POST['details'] not set als in bovenstaande regel de if true is :?
Kijk eens in de HTML-output van je bovenstaande stukje code
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
<input type="checkbox" name="details" value="1" checked="checked" disabled="disabled" />
hij staat dus ook keurig aangevinkt en greyed out.
hij staat dus ook keurig aangevinkt en greyed out.
Ah, ik zag geen PHP-tag halverwege je regel dus dacht dat daar het probleem zat. Maar disabled wordt niet doorgegeven inderdaad. Alternatief is readonly, maar dat werkt in Firefox in ieder geval niet goed. Ander alternatief is met een script vlak voor de submit het veld nog te undisablen.
Maar beter nog is helemaal niet naar deze waarde te kijken, maar gewoon in je script te bedenken wat de waarde zou moeten zijn. User-input is immers nooit te vertrouwen.
Maar beter nog is helemaal niet naar deze waarde te kijken, maar gewoon in je script te bedenken wat de waarde zou moeten zijn. User-input is immers nooit te vertrouwen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
