Hoe optimaliseren van Handler_read_rnd_next 2,82 G

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Jan heide

jan heide

20/10/2007 23:48:00
Quote Anchor link
Hoi Allemaal,

Vraagje als ik bij de mysql Runtime Informatie kijk zie ik bij onderstaande informatie staat. Heeft iemand enig iedee wat ik hieraan kan doen?

Alvast thanx
jan

Handler_read_rnd_next 2,82 G

The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
 
PHP hulp

PHP hulp

28/11/2024 01:55:03
 
Joren de Wit

Joren de Wit

20/10/2007 23:57:00
Quote Anchor link
Quote:
Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.
Indexen juist aanbrengen en gebruiken? Zie ook deze tutorial over indexen.
 
Jan heide

jan heide

21/10/2007 00:31:00
Quote Anchor link
is er een methode om er achter te komen welke tabellen het probleem geven want zover ikweet staat er in elke tabel wel een index. maar zal zowieso de tutor nog eens goed doorlezen :) thanx voor deze tip alvast

kan het overigens veel kwaad zo'n bestand en 2,4 G ?

of:
Verkeer ø per uur
Ontvangen 3 GB 201 MB
Verzonden 650 MB 45 MB
Totaal 3 GB 245 MB

en:
Query statistieken: Sinds het opstarten zijn er, 20.200.605 queries gestuurd naar de server.

en:
Totaal ø per uur ø per minuut ø per seconde
20 M 1,39 M 23,10 k 385,04


Thanx alvast
jan
Gewijzigd op 01/01/1970 01:00:00 door jan heide
 
Frank -

Frank -

21/10/2007 00:37:00
Quote Anchor link
explain jouw_query

Dat is de enige manier.

Edit: Kun je bij het logboek van de database-server komen? daar staat ook veel waardevolle informatie in.

Edit 2: handleiding
Gewijzigd op 01/01/1970 01:00:00 door Frank -
 
Jan heide

jan heide

22/10/2007 14:12:00
Quote Anchor link
@pgFrank: wat bedoel je met explain jouw_query.? want er zijn wel 1000den query's die draaien op gitaartabs..
 
Frank -

Frank -

22/10/2007 17:46:00
Quote Anchor link
jan schreef op 22.10.2007 14:12:
@pgFrank: wat bedoel je met explain jouw_query.? want er zijn wel 1000den query's die draaien op gitaartabs..
Dan mag je dus 1000en keren EXPLAIN gaan draaien.

EXPLAIN is de enige manier om te achterhalen hoe een query wordt uitgevoerd en waar je e.e.a. zou kunnen verbeteren. Wellicht is het handiger om eerst eens uit te zoeken welke pagina's langzaam zijn en dan pas naar de individuele queries te kijken. Wanneer je een database-class hebt gebruikt, kun je eenvoudig een logging inbouwen of vandaaruit de EXPLAIN's gaan draaien.

Maar duik ook eens in de logboeken van de database, die zijn er vast wel, daar wordt je vast ook wijzer van.

Meten is weten.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.