SQL ----------------------------------- SELECT DISTINCT D.DINFO, C.CINFO, B.BINFO, A.NR1, A.NR2, A.ADATE FROM ATABEL A, BTABEL B, CTABEL C, DTABEL D WHERE B.NR1 = \'INDTAST1\' AND B.NR2 LIKE \'INDTAST2%\' AND A.NR1 = B.NR1 AND A.NR2 = B.NR2 AND A.ADATE >= SYSDATE AND C.NR1 = B.NR1 AND C.NR4 = B.NR4 AND D.NR3 = A.NR3 ORDER BY D.DINFO, C.CINFO, B.BINFO
Mød TrackMan og Veo på Computerworld Cloud & AI Festival og hør, hvordan tech ændrer måden, vi træner og udvikler talent – fra skolebold til The Masters.
Dette medfører da også at din indledende SQL er ganske korrekt. Det er nok nærmere et index spørgsmål. Måske skal du prøve at sætte join-betingelserne (alle dem med ligmedtegn (=) i) op forrest og lade dine like og datoting stå til allersidst.
Kommentar til pou_vad: Siden hvornår har MS overholdt SQL ANSI standarden?
Rækkefølgen af tabellerne i FROM kan have noget at sige, prøv med :
SELECT DISTINCT D.DINFO, C.CINFO, B.BINFO, A.NR1, A.NR2, A.ADATE FROM BTABEL B, ATABEL A, CTABEL C, DTABEL D WHERE B.NR1 = \'INDTAST1\' AND B.NR2 LIKE \'INDTAST2%\' AND A.NR1 = B.NR1 AND A.NR2 = B.NR2 AND A.ADATE >= SYSDATE AND C.NR1 = B.NR1 AND C.NR4 = B.NR4 AND D.NR3 = A.NR3 ORDER BY D.DINFO, C.CINFO, B.BINFO
Altså \'hoved\'-tabellen i join først, sådan at når B er fundet, så er det at finde A, C og D ret simple opslag.
Mulighed nummer 2 :
Jeg gætter på din Oracle kører med Cost-based optimizer. Hvis det er tilfældet, så skal du have alle 4 tabeller analyseret, så optimizeren har noget at gå efter :
ANALYZE TABLE ATABEL COMPUTE STATISTICS;
(Du kan bruge ESTIMATE i stedet for COMPUTE - det går hurtigere, men er ikke så sikkert)
Jeg har læst i MS documentationen et eller andet sted at de overholder SQL ANSI standarden - men det passer vel ikke :o)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
