Toon posts:

[sql] Groot aantal queries op statuspagina mysql

Pagina: 1
Acties:

Onderwerpen


  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
Hey,

Wanneer ik in phpmyAdmin op de statuspagina het totaal aantal queries wil bekijken schrik ik elke keer weer :).

Elke keer dat ik de pagina opnieuw inlaadt (elke seconden) komen er wel 100 queries bij op het totale aantal queries. Dit terwijl er geen bezoekers zijn op de website, dus de website is hier niet de schuldige van (lijkt mij).

Is het normaal dat sinds gisteravond al zo'n 160.000 queries zijn uitgevoerd, zonder dat er veel gebruikers online waren?

Ook maak ik goed gebruik van indexes (tevens gecontroleerd met EXPLAIN etc..), maar op de statuspagina staat de:

Handler_read_rnd_next momenteel op 108M.

Het lijkt er wel op dat er veel andere queries worden gedraaid om een duistere reden.

Weet iemand waar dit door zal kunnen komen?

Edit: Ik maak overigens gebruik van PDO

  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
Excuus voor de onduidelijkheid. Het gaat om een VDS, dus geen shared hosting. Zoals gezegd maak ik gebruik van PDO om de query's uit te voeren. Ik heb een functie gemaakt (extenden van PDO class) om het aantal uitgevoerde queries te berekenen op de verschillende pagina's.

Het aantal queries per pagina varieert van 5 tot 10 queries.

Alle bezoekers worden geregistreerd (middels ipadres), waarna ik op de online pagina het aantal bezoekers kan zien (ook kan ik de inactiviteit zien van de leden), dus wanneer leden geen pagina inladen dan worden er nog veel queries uitgevoerd in de database.

De views kan ik zo 1,2,3 niet achterhalen. Maar stel als er 5 bezoekers online zien die in een seconde 3 pagina's bekijken (wat al erg veel is), dan genereren deze dus 3 x 7 x 5 queries. 100 queries in een seconde.

Wat mij ook zorgen baart is de Handler_read_rnd_next die momenteel op 207 M staat. Terwijl ik zeer veel queries door de EXPLAIN heb gehaald en allen gebruiken ze een key of een table scan (in dit geval betreft alleen hele kleine tabellen).

Ook de slow queries staat momenteel op 736 (sinds gisteravond), terwijl er geen queries in de slow-query log komen te staan.

Edit: En hoe de query eruit ziet maakt niet zo veel uit toch? Want 1 query is 1 query toch? Of worden de joins apart mee gerekend?

[Voor 10% gewijzigd door radem205 op 06-10-2010 13:46]


  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
Het is al meerder dagen aan de gang he (dus het kan wel een spider zijn, maar het lijkt mij sterk). En ik heb ook nog geen instellingen aangebracht in my.cnf (aangezien deze gemanaged wordt door de hoster).

De Created_tmp_disk_tables wordt ook vrij hoog, dus dat is een teken dat ik de table_cache moet veranderen.

Edit: En ik gebruik myISAM, waardoor het wel kan zijn dat ik tegen table_locks aanloop.

Edit 2: Table_locks_waited staat op 0 dus dat lijkt mij niet het geval

[Voor 24% gewijzigd door radem205 op 06-10-2010 14:10]


  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
Een spider geeft toch wel een ipadres door tijdens het bezoek? Want deze worden dan wel geregistreerd en komen ook in de lijst met bezoekers (waarvan het aantal dus niet hoog is).

En zoals eerder gezegd wordt er goed gebruik gemaakt van indexes, ik kan daar niet al te veel meer aan verbeteren.

  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
GlowMouse schreef op dinsdag 12 oktober 2010 @ 12:46:
Je kunt MySQL alle queries laten loggen, dan weet je het gelijk :)
Ok, thanks!

Nog even een vraag:

Hoe kan het dat onderstaande query geen indexes gebruikt (index op vriend_in, vriend_uit en actief)? (ik weet dat het komt door de OR condition)

EXPLAIN SELECT id FROM vrienden WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1

Op http://dev.mysql.com/doc/...x-merge-optimization.html zag ik dat dit wel eens het probleem kan zijn, echter beschik ik over mySQL 5.1 maar nog werkt het niet.

  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
GlowMouse schreef op dinsdag 12 oktober 2010 @ 15:53:
Doe eens

SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief

en kijk dan of je snel alle rijen kunt vinden die voldoen aan WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1. Dat zal niet lukken. Dat lukt wel bij het resultaat uit deze twee queries:

SELECT actief,vriend_in FROM vrienden ORDER BY actief,vriend_in
SELECT actief,vriend_uit FROM vrienden ORDER BY actief,vriend_uit

Het filteren van dubbelen is dan wel weer even werk. Je hebt dus minimaal twee indexen nodig wil je deze query volledig met indices uitvoeren.
Ik heb nu even wat geexperimenteerd met indexes, wanneer ik onderstaande indexes plaats dan gebruik hij de "actief,afgekeurd" index wat in mijn ogen inefficiënt is, want dan worden nog steeds 2800 rijen doorlopen:

index 1: vriend_in
index 2: vriend_uit
index 3: actief,afgekeurd

Nu doe ik het waarschijnlijk nog steeds fout, want ik weet niet precies hoe mysql met OR conditions te werk gaat (schijnbaar anders dan verwacht).

Of doe ik het zo wel correct en kan hij alleen de "actief, afgekeurd" index gebruiken?
Creepy schreef op dinsdag 12 oktober 2010 @ 15:58:
EN uiteraard is het ook nog afhankelijk van de inhoud van de tabellen. Als er maar 10 records in staan kan MySQL prima vinden dat een table scan sneller is.
Ja inderdaad, maar het zijn nu (binnen een week) al 2800 records, dus de kans dat dit heel erg gaat oplopen is erg groot.

[Voor 14% gewijzigd door radem205 op 12-10-2010 16:04]


  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
GlowMouse schreef op woensdag 13 oktober 2010 @ 11:03:
[...]

Je moet niet experimenteren, je moet logisch nadenken. Indexen werken als gesorteerde lijsten. Kun jij uit een lijst gesorteerd op vriend_in snel de rijen halen die voldoen aan (vriend_in = 6 OR vriend_uit = 6) AND actief = 1? Zonee, dan helpt een index op vriend_in niet.
Uit een lijst gesorteerd op actief kun je snel de rijen halen met actief=1, maar als dat bijna alle rijen zijn dan heeft dat niet zoveel zin.
Ik snap dat je beter logisch kan nadenken, maar in het leven is logisch nadenken soms erg moeilijk. En wat jij zegt had ik ook al wel bedacht, maar als ik logisch nadenk dan moet een index op "vriend_in, vriend_uit en actief" wel kunnen (want dan kan hij sorteren op vriend_in of vriend_uit en actief). Maar dit werkt dus niet (dit heb ik aanvankelijk al ingesteld).

Dus ik hoop dat je begrijpt dat ik nu niet helemaal weet welke indexen het beste zijn voor mijn query. Kan je mij een eindje op weg helpen?

  • radem205
  • Registratie: juni 2002
  • Laatst online: 20-09-2020
GlowMouse schreef op woensdag 13 oktober 2010 @ 17:16:
[...]

Met die index kan hij helemaal niet sorteren op vriend_uit of actief. Stel je de index voor als het resultaat van
SELECT actief,vriend_in,vriend_uit FROM vrienden ORDER BY vriend_in, vriend_uit en actief


Puur deze query:
SELECT id FROM vrienden WHERE (vriend_in = 6 OR vriend_uit = 6) AND actief = 1
kun je volledig met indexen uitvoeren. Over je tabellay-out zullen we het niet hebben, en komt er een ORDER BY bij, dan kun je het vergeten. Index op (actief,vriend_in) en op (actief,vriend_uit) en dan deze query:
SELECT id FROM vrienden WHERE vriend_in = 6 AND actief = 1
UNION
SELECT id FROM vrienden WHERE vriend_uit = 6 AND actief = 1
Bedankt, dat werkt top! En de tabellay kan beter inderdaad (wellicht per vriendschap 2 rijen), maar met een groot aantal vriendschappen wordt het aantal rijen hiermee verdubbeld (misschien bij nader inzien was dit niet zo'n probleem geweest).
Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee