Loop vast in Union statement
Het klinkt alsof je een bepaalde grens overschrijdt, waarbij je een limiet moet oprekken?
Verder is het logischer dat je MySQL los een restart geeft (staat los van de webserver), maar het zou eigenlijk niet moeten.
Die tabel vervalt ook niet, hij komt er alleen pas later bij.
Ik zal het proberen uit te leggen:
Op het moment dat je GROUP BY in een query gebruikt moet de database eerst alle informatie verzamelen voordat er gegroepeerd wordt. Dit kan (gezien het aantal koppeltabellen) best wel oplopen.
Grofweg:
a = Aantal personen x (gem) aantal rollen pp x (gem) aantal activiteiten per rol x (gem) aantal autorisaties per act.
Terwijl:
b = aantal afdelingen
Door eerst te groeperen in een subquery en daarna pas die tabel te joinen bespaar je dan b t.o.v van a (beetje simpel gesteld)
In je openingsvraag geef je aan dat je FlySpeed als tool hebt, ik denk dat je daar ook 'zelf geschreven' SQL statements kan uitvoeren. In dat geval doe dat, dan sluit je iig uit dat het geen PHP issue is.
- Ariën - op 14/12/2020 20:03:08:
Waarom zou je steeds je webserver moeten herstarten?
Het klinkt alsof je een bepaalde grens overschrijdt, waarbij je een limiet moet oprekken?
Verder is het logischer dat je MySQL los een restart geeft (staat los van de webserver), maar het zou eigenlijk niet moeten.
Het klinkt alsof je een bepaalde grens overschrijdt, waarbij je een limiet moet oprekken?
Verder is het logischer dat je MySQL los een restart geeft (staat los van de webserver), maar het zou eigenlijk niet moeten.
Omdat bij uitvoering de mijn browser maar blijft pollen en draaien.... na een 1/2 uurtje ben ik dat toch wel zat hoor.. en dan forceer ik een herstart want anders kan ik niets anders doen... en mijn van van mijn laptop loopt als 'n dolle te blazen... die raakt klaarblijkelijk verhit
Ger van Steenderen op 15/12/2020 13:58:46:
>> Die tabel is benodigd voor extra informatie over desbeteffende OU.
Die tabel vervalt ook niet, hij komt er alleen pas later bij.
Ik zal het proberen uit te leggen:
Op het moment dat je GROUP BY in een query gebruikt moet de database eerst alle informatie verzamelen voordat er gegroepeerd wordt. Dit kan (gezien het aantal koppeltabellen) best wel oplopen.
Grofweg:
a = Aantal personen x (gem) aantal rollen pp x (gem) aantal activiteiten per rol x (gem) aantal autorisaties per act.
Terwijl:
b = aantal afdelingen
Door eerst te groeperen in een subquery en daarna pas die tabel te joinen bespaar je dan b t.o.v van a (beetje simpel gesteld)
In je openingsvraag geef je aan dat je FlySpeed als tool hebt, ik denk dat je daar ook 'zelf geschreven' SQL statements kan uitvoeren. In dat geval doe dat, dan sluit je iig uit dat het geen PHP issue is.
Die tabel vervalt ook niet, hij komt er alleen pas later bij.
Ik zal het proberen uit te leggen:
Op het moment dat je GROUP BY in een query gebruikt moet de database eerst alle informatie verzamelen voordat er gegroepeerd wordt. Dit kan (gezien het aantal koppeltabellen) best wel oplopen.
Grofweg:
a = Aantal personen x (gem) aantal rollen pp x (gem) aantal activiteiten per rol x (gem) aantal autorisaties per act.
Terwijl:
b = aantal afdelingen
Door eerst te groeperen in een subquery en daarna pas die tabel te joinen bespaar je dan b t.o.v van a (beetje simpel gesteld)
In je openingsvraag geef je aan dat je FlySpeed als tool hebt, ik denk dat je daar ook 'zelf geschreven' SQL statements kan uitvoeren. In dat geval doe dat, dan sluit je iig uit dat het geen PHP issue is.
ik voer ook inderdaad ook eerst de sql statements in flyspeed... dat gaat wel maar tot aan de tabel ou.... want voeg ik die toe dan zegt ie mooi 'doet 't lekker zelf' :-) voor nu zie ik dit op mijn laptop als onmogelijk en er is al heel veel gezegd en geschreven hierover. Ben ook erkentelijk voor al die voorzetten, opmerkingen en aanvullingen maar het is simpelweg niet te doen. Kan geen andere conclusie trekke. Wederom gaat mijn dank uit naar iedereen die een bijdrage heeft geleverd aan dit topic.
Het is wel lastig wanneer MySQL om onbekende reden blijft hangen. Ik heb dat ooit gehad op een server met ZFS als bestandssysteem op FreeBSD. Nadat ik terug ging naar UFS was het probleem verholpen.
In jouw geval zou ik via een tweede verbinding met MySQL vanuit een client kijken welk proces lang draait met de query SHOW PROCESSLIST; en eventueel door te kijken in het slow query log. Zodra je weet op welke SQL de database blijft hangen kan je de prestaties analyseren via EXPLAIN ANALYZE. Maar je kunt ook de query stapsgewijs uitvoeren (steeds meer JOINs en condities) en die stuk voor stuk uitproberen om te kijken waar het probleem zit.
Je kunt queries meestal wel goed optimaliseren met goed geplaatste indices (voor als je minder dan 15% van de rijen nodig hebt). Verder maakt de volgorde van JOINs soms uit, en wat ook uitmaakt zijn de WHERE-condities. Informatie aggregeren zoals met GROUP BY wil je het liefst in een zo laat mogelijk stadium doen en waar mogelijk met Window-functies. Als het niet genoeg helpt kan je eventueel nog tijdelijke (sessie-)tabellen gebruiken.
Deze info is meer algemeen van aard, toch hoop ik dat er iets tussenzit waarmee je verder komt.