SQL Nachhilfe

[hoika]

Hallo,
das Year-Dingens könnte man so umschreiben

DateAdd("yyyy", -5, Date())

Aber warum übergibst Du das nicht als konstanten Parameter?
Warum wird das jedesmal berechnet?

Und noch mal auf die Indizes zu kommen.
INNER JOIN ABFPos as P ON A.ABFDocId = P.ABFPosDocID )
inner join sPersKto as M on M.PersKtoNummer = A.ABFDocKundenNr
where P.ABFPosArtNr = '11024060' and Year([A.ABFDocDatum]) > Year(Date())-5 and A.ABFDocType = 1


Die fett markierten Felder müssten Indizes enthalten.

Ich würde danach auch mal die MDB komprimieren.

[himitsu]

Das DateAdd("yyyy", -5, Date()) wird nur einmal berechnet. (außer die haben bei der Funktion und dem Queryplaner echt Scheiße gebaut)

Aber das Date vom Feld, wird natürlich für jeden Datensatz berechnet.
Ja, die Berechnung/Funktionsausführung dauert nicht lange und braucht nahezu keine Zeit,
aber da es keinen Index auf dessen Ergebnis gibt, kann eben auch Keiner genutzt werden.

[hoika]

Hallo,
kein Index?

CREATE INDEX idx_ABFDok_ABFPosArtNr_Datum_Type_KundenNr ON ABFDok (ABFPosArtNr, ABFDocDatum, ABFDocType, ABFDocKundenNr);


Eventuell sollte noch ein Index direkt auf ABFDocDatum gesetzt werden, also nicht so ein "komischer" Compound-Index.

[himitsu]

idx_ABFDok_ABFPosArtNr_Datum_Type_KundenNr ist ein Combi-Index, der genutzt wird, wenn im WHERE direkt auf alle Felder (ABFPosArtNr, ABFDocDatum, ABFDocType, ABFDocKundenNr) gerpft wird.

Hast du einen Index nur auf "ABFDocDatum", also CREATE INDEX idx_ABFDocDatum ON ABFDok (ABFDocDatum); (oder z.B. ABFDocDatum UNIQUE im CREATE TABLE), dann
* wird bei WHERE ABFDocDatum ... dieser Index benutzt
* aber nicht bei WHERE Year(ABFDocDatum) ...

Für Letzteres bräuchte man z.B. sowas CREATE INDEX idx_YearABFDocDatum ON ABFDok (Year(ABFDocDatum)); (falls Access sowas kann)



Und wie gesagt, kommt es teilweise auch auch auf die Art des Indize drauf an.
MySQL oder z.B. Postgres kennen unterschiedliche Typen (z.B. B-tree, hash, GiST, SP-GiST, GIN, and BRIN)

B-Tree ist heute oft gebräuchlich und auch für ein LIKE 'irgendwas*' geeignet, während HASH für ein LIKE absolut unnütz ist, aber für ein = mit langen Strings super wäre.
Und für LIKE '*sonstwas' wäre es besser, wenn der B-Tree rückwärts von hinten aufgebaut ist.