AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

DB Tabelle beschleunigen

Ein Thema von Ykcim · begonnen am 12. Jul 2019 · letzter Beitrag vom 18. Jul 2019
Antwort Antwort
Delphi.Narium

Registriert seit: 27. Nov 2017
2.578 Beiträge
 
Delphi 7 Professional
 
#1

AW: DB Tabelle beschleunigen

  Alt 12. Jul 2019, 15:40
SQL-Code:
select max(a.waaunr) from as400archiev as a
where a.watenr = :artikel
and left(a.oamanr,2) in
(SELECT arbeitsplatzkz from bereiche where bereiche_text = :bereich)
group by a.oamanr
Zuerst: wielange dauert das?

SELECT arbeitsplatzkz from bereiche where bereiche_text = :bereich

Wie lange dauert es, wenn Du einen Index auf bereiche_text erstellst?

Funktioniert das? Wird es schneller?
SQL-Code:
select max(a.waaunr) from as400archiev a, bereiche b
where a.watenr = :artikel
and left(a.oamanr,2) = b.arbeitsplatzkz
and bereiche_text = :bereich
group by a.oamanr
Alternativ:
SQL-Code:
select max(a.waaunr) from as400archiev a
inner join bereiche b on left(a.oamanr,2) = b.arbeitsplatzkz
where a.watenr = :artikel
and b.bereiche_text = :bereich
group by a.oamanr
Alles nur ungetestet hingedaddelt.

Sowas left(a.oamanr,2) in 'ner Wherebedingung ist nicht gerade dafür bekannt, dass entsprechende Abfragen schnell werden, in der Regel schließt sowas eine Indexnutzung aus.

Auch ein in (select spalte from tabelle) in einer Wherebedingung ist nicht zwingend zur Beschleunigung einer Abfrage geeignet, eher das Gegenteil.

Achso: Und einfache Abfragen sind das ganz und gar nicht, die Schwierigkeit einer Abfrage ergibt sich nicht daraus, ob es schwierig ist sie zu schreiben, sie zu formulieren, sondern daraus, wie schwierig ihre Ausführung für die Datenbank wird.

Schlimmste Laufzeitannahme:

Wenn Deine Tabelle 2.5 Mio Datensätze hat und Du per left(a.oamanr,2) für jeden Datensatz eine Einschränkung baust, so muss die Datenbank 2,5 Mio mal eben diesen Substring bilden. Und dann muss sie 2.5 Mio mal dieses SQL SELECT arbeitsplatzkz from bereiche where bereiche_text = :bereich ausführen, obwohl es eigentlich immer das gleiche Ergebnis liefert.
Dann muss sie sich alle die Sätze merken, bei der die Bedingung zutrifft und anschließend davon den Satz mit der größten waaunr je oamanr auswählen.

Für meine Begriffe sind bei dem Aufwand die Antwortzeiten ja eigentlich garnicht mal so übel
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.879 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: DB Tabelle beschleunigen

  Alt 12. Jul 2019, 15:49
Zitat:
Sowas left(a.oamanr,2) in 'ner Wherebedingung ist nicht gerade dafür bekannt, dass entsprechende Abfragen schnell werden, in der Regel schließt sowas eine Indexnutzung aus.
Oder man erstellt ein "Schattenfeld" oder einen expression index
Markus Kinzler
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.578 Beiträge
 
Delphi 7 Professional
 
#3

AW: DB Tabelle beschleunigen

  Alt 12. Jul 2019, 15:53
Zitat:
Sowas left(a.oamanr,2) in 'ner Wherebedingung ist nicht gerade dafür bekannt, dass entsprechende Abfragen schnell werden, in der Regel schließt sowas eine Indexnutzung aus.
Oder man erstellt ein "Schattenfeld" oder einen expression index
Ja durchaus, aber hier kommen wir dann in den Bereich der Optimierung für Fortgeschrittene

Momentan ist aber noch unklar, was ein Index überhaupt ist.
  Mit Zitat antworten Zitat
Antwort Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:55 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz