[sql] Performance probleempje

[eppie]

Hallo,

Ik zit met een sql probleem waar ik niet echt uit kom

Msttr bevat de records art_no (artikel nummer) en cu_sup_no (klant code) en bevat zo'n 450.000 records.
Mart bevat de records art_no (artikel nummer) en art_desc (artikel omschrijving) en bevat zo'n 100.000 records.

Nou wil ik uit msttr alle artikel nummers die een bepaalde klant gekocht heeft halen en daar dan de omschrijving bij vinden.

Als ik in mijn programma eerst alle artikel nummers ophaal uit msttr voor een klant en dan de omschrijving uit mart haal gaat dit erg snel maar zodra ik dit in 1 query wil doen duurt het 3 minuten en langer .

de 2 losse query's:

SQL:

SELECT distinct art_no FROM msttr WHERE cu_sup_no = klant code;
SELECT art_desc FROM mart WHERE art_no = artikel code ;

Bij deze query's duurt het gewoon erg lang

SQL:

SELECT mart.art_no, mart.art_desc FROM mart INNER JOIN msttr ON mart.art_no =
 msttr.art_no WHERE msttr.cu_sup_no = klant code;

SELECT mart.art_no, mart.art_desc FROM mart, msttr WHERE msttr.cu_sup_no = 
klant code AND msttr.art_no = mart.art_no;

Subquery's worden niet ondersteund door deze versie van mysql (4.0).

Wat is er fout aan deze query's waardoor het zo lang duurt?

Ik kan het natuurlijk wel door middel van die 2 aparte query's doen maar dat lijkt me niet erg netjes.

Alvast bedankt.

[whoami]

Heb je indexen op je tabel ? (op de columns msttr.cu_sup_no en mart.art_no en msttr.art_no)?

[Verwijderd]

eppie schreef op dinsdag 21 december 2004 @ 10:55:
Nou wil ik uit msttr alle artikel nummers die een bepaalde klant gekocht heeft halen en daar dan de omschrijving bij vinden.

Waarom doe je niet gewoon een join?

SQL:

Select Distinct mart.Art_No, mart.Art_desc 
from Mssttr, Mart 
where Mssttr.Artno=Mart.ArtNo AND cu_sup_no=12345

[eppie]

Nee zijn geen indexen.

[whoami]

eppie schreef op dinsdag 21 december 2004 @ 11:04:
Nee zijn geen indexen.

Plaats er dan.

Regel 1: zet indexen op columns waarop je zoekt of joined. Als je dat niet doet, dan moet het DBMS een table scan gaan uitvoeren om jouw query te gaan uitvoeren, en dan is het vanzelfsprekend dat je query traag gaat....

Verwijderd schreef op dinsdag 21 december 2004 @ 11:03:
[...]


Waarom doe je niet gewoon een join?

SQL:

Select Distinct mart.Art_No, mart.Art_desc 
from Mssttr, Mart 
where Mssttr.Artno=Mart.ArtNo AND cu_sup_no=12345

Dat doet hij.

[ Voor 75% gewijzigd door whoami op 21-12-2004 11:06 ]

[eppie]

Zal het is proberen bedankt voor de snelle reply's.

Dit word gekopieert uit een nogal oude database die nog nooit van indexen, keys enz gehoord heeft

[Bosmonster]

Bedenk bij het zetten van indices dat MySQL maar 1 index per query kan gebruiken. Losse indices op alle velden heeft dus weinig nut. Je zult per query moeten kijken wat je nodig hebt.

[whoami]

Bosmonster schreef op dinsdag 21 december 2004 @ 11:29:
Bedenk bij het zetten van indices dat MySQL maar 1 index per query kan gebruiken. Losse indices op alle velden heeft dus weinig nut. Je zult per query moeten kijken wat je nodig hebt.

OMG.

[P_de_B]

Bosmonster schreef op dinsdag 21 december 2004 @ 11:29:
Bedenk bij het zetten van indices dat MySQL maar 1 index per query kan gebruiken. Losse indices op alle velden heeft dus weinig nut. Je zult per query moeten kijken wat je nodig hebt.

dus als je ergens een primary key op zet, kun je geen verdere indexen gebruiken?

[Bosmonster]

P_de_B schreef op dinsdag 21 december 2004 @ 11:35:
[...]


dus als je ergens een primary key op zet, kun je geen verdere indexen gebruiken?

Je kunt er zoveel aanmaken als je wilt, hij kan er alleen maar 1 gebruiken Je zult dus indices van gecombineerde velden moeten maken (wil je iets hebben met een bepaalde eigenschap gesorteerd op datum, dan moet je een index maken met die eigenschap + datum).

Maak je ze los (index eigenschap + index datum) dan zal die er eentje uitzoeken die die leuk vindt

[ Voor 36% gewijzigd door Bosmonster op 21-12-2004 12:08 ]

[RobIII]

Bosmonster schreef op dinsdag 21 december 2004 @ 12:07:
[...]


Je kunt er zoveel aanmaken als je wilt, hij kan er alleen maar 1 gebruiken Je zult dus indices van gecombineerde velden moeten maken (wil je iets hebben met een bepaalde eigenschap gesorteerd op datum, dan moet je een index maken met die eigenschap + datum).

Maak je ze los (index eigenschap + index datum) dan zal die er eentje uitzoeken die die leuk vindt

offtopic:
Was jij dat niet met zo'n ernorme waslijst aan punten die nog "mankeerden" aan MySQL die opgelost "zouden moeten worden" alvoor het uberhaupt aan RDBMS gezien mocht worden? En zo ja, waar is die lijst te vinden? Ik heb er toendertijd dubbel om gelegen, en nu ik dit zo weer lees.. tja.. dan denk ik weer aan die lijst en wil ik 'm nog wel eens een keertje hebben

[ Voor 12% gewijzigd door RobIII op 21-12-2004 13:19 ]

[Bosmonster]

Dat was drm volgens mij...

[TeeDee]

RobIII schreef op dinsdag 21 december 2004 @ 13:18:
[...]

offtopic:
Was jij dat niet met zo'n ernorme waslijst aan punten die nog "mankeerden" aan MySQL die opgelost "zouden moeten worden" alvoor het uberhaupt aan RDBMS gezien mocht worden? En zo ja, waar is die lijst te vinden? Ik heb er toendertijd dubbel om gelegen, en nu ik dit zo weer lees.. tja.. dan denk ik weer aan die lijst en wil ik 'm nog wel eens een keertje hebben

offtopic:
afaik was dat ACM

[RobIII]

TeeDee schreef op dinsdag 21 december 2004 @ 13:21:
[...]

offtopic:
afaik was dat ACM

offtopic:
ACM dus ja
http://vulcanus.its.tudelft.nl/acm/got/antimysql.php
Thanks

[_js_]

Bosmonster schreef op dinsdag 21 december 2004 @ 11:29:
Bedenk bij het zetten van indices dat MySQL maar 1 index per query kan gebruiken. Losse indices op alle velden heeft dus weinig nut. Je zult per query moeten kijken wat je nodig hebt.

MySQL gebruikt 1 index voor de WHERE/GROUP BY/ORDER BY, maar hij kan wel per join nog een index gebruiken voor die join.

[ Voor 18% gewijzigd door _js_ op 21-12-2004 16:39 ]