Afdrukvoorbeeld
Dat wordt zeker sneller ja... als je je data nl. in een tree sorteert die oplopend is opgebouwd weet je dat als je een bepaalde waarde gevonden hebt, de volgende waarden automatisch ook groter danwel kleiner zijn.
Bovendien: de Query-cache van MySQL wordt NOOIT gebruikt als er een NOT (in welke vorm dan ook) in voorkomt. Bij een groterdan of kleinerdan wel. Dus al zou de query er 2x zo lang over doen, dan is het nog altijd sneller dan 3x de vorige query. :)
Waar haal je deze 'wijsheid' vandaan? Heb je hier een bron voor, of is dit iets wat je zelf bedacht hebt?
Ik vraag me echt af of je dit serieus bedoeld...
De claim die gemaakt wordt is zeker correct!
Als je wil weten hoe het werkt, lees even na hoe de BTREE-datastructuur ineen steekt, en lees dan even na hoe MySQL zijn indexen opbouwt en gebruikt. Zorg ervoor dat je mysql zolang mogelijk zijn index kan blijven gebruiken; en denk eraan dat het een geordende datastructuur is (> of < geeft orde aan, != niet). Tuning primer is een prima script, maar lees wat het zegt, toets het aan je eigen situatie en ga dan pas acties ondernemen. Het is een tool, geen oplossing.
Het optimaliseren van queries kan een gigantisch verschil geven; soms is 1 query verantwoordelijk voor slechte performantie van een hele server.
Hoofdstuk 7 van de mysql manual is ook zeer intressant te noemen, en zeker deel 7.2: http://dev.mysql.com/doc/refman/5.0/en/query-speed.html. Echter, ik wil benadrukken dat je het moet lezen, en begrijpen voor je maar "mysql" durft te tikken op je server! Wild en zonder clue tekeer gaan in je DB is nooit goed.
Dat optimaliseren slim is twijfel ik niet aan, dat een query met NOT er in meer tijd kost ook niet.
Het gaat er bij mij alleen niet in dat een UNION van een > en < query sneller gaat zijn dan een != query. Een UNION kost ook tijd, vooral als je daarna de data nog eens wil sorteren, of ook op andere data wil selecteren. Ik heb geen enkele informatie gevonden voor deze claim, graag hoor ik van een van jullie waar ik dan overheen lees...
Ben er nog even over in discussie gegaan op #mysql on FreeNode, volgens de mensen daar heeft de UNION geen snelheidswinst. Afhankelijk van het percentage wat uitgesloten wordt is een table scan in de meeste gevallen sneller dan het gebruik van een index. Daarna volgde een hele discussie over welke storage engine je het beste kon gebruiken en dergelijke, maar dat gaat voor hier wat te ver.
Ik blijf van mening dat het gebruik van != 0 op geen andere snellere manier kan worden opgelost, ook niet door een UNION van > 0 en < 0. Graag zie ik wat meer argumenten dan alleen "De claim die gemaakt wordt is zeker correct!".
Ok, geen probleem dan. Wel vreemd dat je om raad vraagt en die dan in twijfel gaat trekken (al is het natuurlijk zeker niet verkeerd om kritisch te zijn naar input toe).
Ik zou je aanraden om dan maar eens een benchmark te laten lopen.
Voor jou specifieke query: probeer een index te maken voor je sort-velden, in de volgorde van je sort. Dat zou je "using filesort" moeten wegwerken.
Ik vraag niet om raad, ik ben niet de TS. Ik heb geen probleem queries, ik reageerde alleen op de bewering van Jurrian. Volgens mij is die bewering onjuist.Citaat:
Oorspronkelijk geplaatst door wonko
Zoals ik al eerder aangaf: de UNION hoeft niet sneller te zijn dan de NOT, maar de query met de UNION kan wel gecached worden; de NOT-query niet (en evt. een variant met < 0 OR > 0 ook niet, want OR en caching gaan volgens mij ook niet goed samen). De cache zal de snelheidswinst leveren.
Hoe ik aan die wijsheid kom? Dagelijks werken met complexe queries op grote datasets (tabellen met een paar miljoen records, een paar keer gejoined tegen andere tabellen met veel records) in MySQL, 'High performance MySQL' lezen, documentatie lezen bij MySQL, al je SELECT-queries een keer uitvoeren met EXPLAIN ervoor (en niet alleen op je test- of ontwikkelomgeving; MySQL kan met een ander dataset heel andere beslissingen nemen) en natuurlijk ook gewoon veel uitproberen.
Op welke bladzijde van "High performance MySQL" staat dit dan beschreven? Ik heb het boek hier liggen, maar ik zie wat jij beweerd er nergens in staan en kan het ook nergens anders terug vinden.Citaat:
Oorspronkelijk geplaatst door jurrian