Office: (Office 2013) Abfrage 2 Tabellen aus 2 SQL Datenbanken sehr langsam

Danke Josef,

das wusste ich nicht, dass hierdurch z.B. ein Index außer Kraft gesetzt wird, sehr wichtig zu wissen *biggrin.gif*

Es ist jedoch so, dass ich mit Like '1*' auch 5 Sekunden Ladezeit habe.

Die 0,5 Sekunden sind bis zum Anzeigen, du hast Recht die anderen Datensätze werden ja erst beim Scrollen geladen richtig?

Aber andere, viel größere Tabellen werden x-mal schneller geladen, wo ich kein Join und kein Like nutze. Alle Performance-Optimierungen die ich teste fühlen sich an wie ein Tropfen auf den heißen Stein und bringen vielleicht ein paar %, aber wie bekomme ich die 5 Sekunden meiner Access-Abfrage auf deutlich unter 1 Sekunde mit Filterung, oder geht das gar nicht?!

Btw: Die Tabelle ist nicht so groß, wir reden von 500 Datensätzen mit 10-15 Spalten...

 

Generell: Auf etwas allgemeine Prosa kann man dann auch i.d.R. nur mit allgemeiner Prosa antworten. Ob sich dann der Einzelne etwas Konkretes ableiten kann, könnte fraglich sein. Und dann kann man nicht wissen, sondern in großen Teilen vermuten, interpretieren oder unterstellen.

Nein.
Code:

Aber eine Berechnung auf ein Tabellenfeld verhindert zuverlässig die Nutzung eines Index auf dieses Feld. Als Nebenfrage: Warum fragt man Teilinhalte ab? Nicht ohne Grund verlangt die 1. Normalform, atomare Inhalte zu speichern. DAS hat allerdings Auswirkungen auf Strukturen und ggf. Umprogrammierung.

Den zweiten Punkt von sonic8 hast Du zwar gut gefunden, aber von einer Umsetzung bzw. sogar vom wirklichen Verstehen scheinst Du noch deutlich entfernt zu sein.

Du kannst nicht einfach Anweisungen addieren, zumal in der genannten Konstellation nicht. Die Accessabfrage arbeitet mit Jet-SQL und holt sich die Daten von den Backends lokal in die eigene Verarbeitung. Da entsteht Datentraffic. Dann muss Jet mit dem SQL-Dialekt von MySQL kommunizieren. Von einem 1:1-Verständnis kann man sicher nicht ausgehen, also werden dann Teilergebnisse und dann wahrscheinlich mehrfach geliefert, also weiterer Traffic als der zu erwartende.
Traffic muss bewältigt werden, erhaltene Daten müssen im Speicher gehalten werden, größere Mengen nehmen dann zusätzlich am Austausch mit der Auslagerungsdatei teil mit entsprechenden Folgen letztendlich auf Performance. Aufwand wie dann auch ungeschickt eingeleiteter Zusatzaufwand benötigen Zeit. Ja, das ist eigentlich simpel.

Abgeleitet daraus:
- Wenn man die MySQL-DB's derart zusammenführen kann, dass die Abfrage dort als View ausgeführt wird, hat man etliche der genannten Probleme nicht. Da würde man im Idealfall nur die Ergebnismenge abrufen.

- Bezüglich Prosa über Abfrage bzw. dann dem ersten Häppchen an Konkretheit:
Naheliegend wäre m.M. nach, einfach mal die vollständige SQL-Anweisung einer betroffenen Abfrage vorzustellen, um daran zu prüfen, ob eine zweckmäßige Umformulierung möglich ist und wie diese aussehen könnte - und die mit einem Test überprüfbar wäre.
Ob Du dann an Hand eines konkreten Beispieles dann verallgemeinern kannst, wäre dann möglicherweise ein folgender Schritt.

 

Danke für deine Rückmeldung. Ich freue mich dass du helfen willst, würde mich jedoch auch freuen wenn du mich nicht als blöd hinstellst sondern wenn du schon antwortest auch versuchst konstruktiv zu sein und Verständnis für meine doofen Fragen zu haben. Ich hingegen bemühe mich die Fragen bestmöglich zu stellen, im Rahmen meiner Möglichkeiten, denn meine Erfahrung hier ist begrenzt. Wenn ich die Fragen gleich korrekt formulieren könnte hätte ich vielleicht auch schon die Antwort, soll heißen ich habe das Thema nicht ohne Grund aufgemacht, sondern weil ich nicht weiterkomme und dazulernen möchte.



Zu Punkt 1:
Ich möchte ein endlosformular in jeder Spalte live filtern können, als Suchfunktion. z.B. einen Namen Müller mit der Eingabe von "Mü" bereits finden, d.h. nach jedem Buchstaben wird die gefilterte Ansicht mit "Like ..." aktualisiert.
Zusätzlich kann man mehrere Spalten parallel in den Filter hineinnehmen, also "LIKE ... AND LIKE ...". Dies performant hinzubekommen ist natürlich nicht ganz einfach, aber bisher lief es immer gut und ist unglaublich praktisch (mit server-seitigen VIEWs)
...ist dieser Bedarf so ungewöhnlich? Heißt atomar speichern, ich muss jeden Buchstaben des Kunden einzeln abspeichern? (rhetorische Frage *biggrin.gif*)

Zu Punkt 2:
Ich denke ich habe das schon verstanden, aber durch das parallele Filtern verschiedener Spalten (die sich womöglich auf verschiedene Basistabellen beziehen) habe ich den Eindruck, das wäre sehr aufwendig, da ich meine gesamte Filterfunktion auf den Kopf stellen müsste. Natürlich schließe ich nicht aus etwas falsch verstanden zu haben, dann erleuchte mich doch bitte *tongue.gif*

Zu Punkt 3:
Was meinst du mit "Addieren" und was ist die Alternative?



Ich danke für deine Hilfe!




PS: ich gehe bei Access immer pragmatisch ran, und setze Funktionen einfach so um dass sie funktionieren. Dass die Performance dabei nicht immer perfekt und optimal ist nehme ich aus Zeitgründen in Kauf, außer die Performance wird sprunghaft so schlecht wie hier, so kann man natürlich nicht arbeiten.

 

Den Begriff atomare Information kann man sich selber erarbeiten. Aber eigentlich verstehen das auch die typischen Excelverwender ohne Zusatzerklärung.

Ist das unverständlich?
Wie Du wahrgenommen wirst, bestimmst Du selber durch schlüssiges Handeln.

 

Hallo,
Code:

Nein, aber um bei dem Beispiel zu bleiben, Vorname und Nachname in getrennten Spalten.
Wenn Du wie hier
Code:

nach dem 1.Zeichen fragst, so hat dieses Zeichen (hier eine 1) ein Bedeutung. Daher ist dieses eine Zeichen in ein extra Spalte auszulagern. Und diese Spalte dann indiziert würde auch einen Index nutzen können. Wenn sich z.B. eine Artikelnummer aus einer Artikelgruppe (z.B. A-G) und einer Lfdnummer zusammensetzt, so ist die Gruppe in einer getennten Spalte zu speichern. Die Artikelnummer selbst wird dann gar nicht gespeichert sondern nur aus der Gruppe und der Lfdnummer zur Anzeige zusammengesetzt.

 

\@ebs17:

gut, dann nicht konstruktiv und verständnisvoll...

Du schreibst "Als Nebenfrage: Warum fragt man Teilinhalte ab? Nicht ohne Grund verlangt die 1. Normalform, atomare Inhalte zu speichern."

Ich sage, ich möchte teile des Namen "Müller" mit Live-Eingabe suchen können.

Du erwiderst dass ich wohl zu dumm bin das Wort atomar zu verstehen.

Dein Ernst? Kannst du mir erklären warum dies wohl keine zufriedenstellende Antwort auf deine Nebenfrage war?

 

Nein, aber um bei dem Beispiel zu bleiben, Vorname und Nachname in getrennten Spalten.
Wenn Du wie hier
Code:

nach dem 1.Zeichen fragst, so hat dieses Zeichen (hier eine 1) ein Bedeutung. Daher ist dieses eine Zeichen in ein extra Spalte auszulagern. Und diese Spalte dann indiziert würde auch einen Index nutzen können. Wenn sich z.B. eine Artikelnummer aus einer Artikegruppe (z.B. A-G) und einer Lfdnummer zusammensetzt, so ist die Gruppe in einer getennten Spalte zu speichern. Die Artikelnummer selbst wird dann gar nicht gespeichert sondern nur aus der Gruppe und der Lfdnummer zur Anzeige zusammengesetzt.

Danke dir für deine Antwort. *Smilie

ganz klar, Vor und Nachnamen sind z.B. getrennt.

Die 1 war nur ein Beispiel, ich möchte z.B. teile einer 15-Stelligen Rechnungsnummer suchen können, also z.B. auch "123" und jede Rechnung anzeigen, die "123" enthält. Ich weiß nicht was ich hier noch auslagern sollte!? Ich denke die Normalformen habe ich schon erfüllt.. Ich möchte einfach eine sehr komfortable Suchfunktion, frage mich grad warum das so unüblich zu sein scheint *biggrin.gif*

 

Die hast Du offensichtlich bereits.
Meine Hinweise gehen eher in die Richtung des performanten Findens.

Da Du sichtbar sehr selektiv liest, gebe ich Dir Zeit, das bisherige im Thema etwas vollständiger zu erschließen.

 

Hallo!

Dauert bereits eine Select-Anweisung nur auf diese Tabelle lange?
Oder meinst du eine Select-Anweisung, die diese Tabelle und andere enthält?

Tipp zum Testen, damit wir eine Chance haben, das Problem zu erkennen:

Luftcode:
Code:

 

Hallo,
man muss sich auch überlegen, ob man zur Suche nicht das sehr komfortable Kombinationsfeld benutzt. Damit kann man zum einen schon mal sicherstellen dass man keinen Tippfehler macht und zum anderen bietet ein Kombinationsfeld genau diese Filterung auf jedes weitere Zeichen automatisch an. Im Kombi kann man zusätzlich weitere Spalten anzeigen um das Finden der richtigen Rechnung zu erleichtern. Dann ein Mausklick und die gesuchte Rechnung ist zu sehen.
Das gilt sicher auch für andere Spalten.

 

In Ergänzung zu der Diskussion über die technische Umsetzung der Abfragen noch eine konzeptionelle Anmerkung.

Ist es sinnvoll nach der Eingabe von jedem Buchstaben zu filtern?

Ein halbwegs versierter Benutzer hat vermutlich "müll" schneller getippt, als die einmalige Ausführung der Suche dauert. Geschweige denn die viermalige, für jeden einzelnen zusätzlichen Buchstaben.

Die Suche erst nach Enter oder verzögert über einen Timer auszulösen bringt möglicherweise für den Benutzer eine weitaus größere, gefühlte Performanceverbesserung als manches Abfragetuning.

Nebenbei doch noch eine technische Anmerkung:
LIKE 'Müll*' und LIKE '*Müll*' unterscheiden sich von der internen Ausführung erheblich. Die erste Variante kann einen Index nutzen, die zweite nicht.

Vielleicht ist es auch hier Benutzerfreundlicher (durch eine schnellere Anwendung), wenn man vom Benutzer erwartet, führende Sternchen selbst einzugeben um seinen Wunsch nach der Suche einer Teilzeichenfolge mitten im Wort Ausdruck zu verleihen.

 

@josef:

Vielen Dank, das grenzt ja das Problem schon mal super ein.
Habe ich alles gemacht, jeweils auf die kombinierte Access Abfrage:

LaufzeitTest "select * from DeineTabelle"

473; 0,54 Sek

LaufzeitTest "select Top 1 * from DeineTabelle"

1; 0,62 Sek

LaufzeitTest "select Top 1 IndiziertesDatenfeld from DeineTabelle Order by IndiziertesDatenfeld"

1; 0,46 Sek


Das sieht doch alles ganz gut aus und die Indizierung scheint zu funktionieren, richtig?

Wenn ich nun aber eine Where Bedingung mit * einbaue:

LaufzeitTest "select IndiziertesDatenfeld from DeineTabelle WHERE IndiziertesDatenfeld LIKE '1*'"

335; 14,01 (!!!) Sek, wie bekomme ich eine *-Suche schneller (unter 1 Sek) hin?
(Größe der Abfrage: ca. 26 Spalten, Größe der Quelltabellen: die eine ca. 10 und die andere ca. 20 Spalten)


PS: ich habe hier jeweils die Access-Abfrage genutzt, die bereits auf die 2 Tabellen der 2 verschiedneen DBs zugreift. Die kombinierte Selectabfrage läuft hierbei offensichtlich sehr flott, nur die WHERE Bedingungen mit * nicht. Hier liegt also das Problem. Es tritt soweit ich sehe aber nur so extrem auf, wenn ich auf Tabellen der beiden verschiedenen DBs zugreife, also in dieser Kombination.





@gpswanderer:

Vielen Dank, auch ein super Tipp *Smilie ich werde verstärkt aufs Kombifeld setzen. Es ist tatsächlich in jedem Fall performanter, löst hier das Problem aber nicht so ganz, da ich selbst bei dieser Einzelabfrage einer Spalte bereits 4-5 Sekunden Wartezeit habe *frown.gif*




@sonic8:

du hast absolut recht, eine Suche erst bei "Enter" wäre deutlich performanter, ein super Tipp! Bisher war die Suche allerdings performant genug, bei mehr Datensätzen bin ich sicher dass ich es wie von dir hier vorgeschlagen umstellen muss. Es löst aber auch hier das Problem nicht ganz, da ich dann trotzdem noch eine Wartezeit von einigen Sekunden habe, auch bei einmaligem Ausführen.

Durch den Test von Josef weiß ich nun auch, dass es nicht meine unperformant gebaute Suchfunktion ist, sondern bereits einfach nur eine Where-Abfrage mit *, die bereits viel zu lange dauert, und die ich irgendwie lösen muss, dann läuft vermutlich auch der ganze Rest.


Ich danke euch sehr für eure Hilfe!! *Smilie

 

Daher die richtungweisende Empfehlung von sonic8 weiter oben, erst zu filtern und danach zu verknüpfen.
Daher könnte man zur Vervollständigung von Tests Tabelle als Begriff wörtlich nehmen, ehe man eine Verallgemeinerung zu WHERE vornimmt.
Weiter könnte man einen Test derart ergänzen, dass man auf Gleichheit filtert (um den Begriff atomare Information aufzuwärmen) statt da eine Mustersuche vorzunehmen.

Relevant für eine Abfrage wären erst einmal die Datensatzzahlen der Quelltabellen. Spalten spielen vor allem dann eine Rolle, wenn sie in Operationen wie Verknüpfen, Filtern, Sortieren, Gruppieren verwendet werden, damit dann auch die dafür nutzbaren Indizes.

 

ebs17, lass es doch bitte einfach bleiben, für mich ist deine Sprache nicht verständlich und du wirkst auf mich auch nicht so als ob du helfen willst. Du fokussierst dich auf die Suche meiner angeblichen Fehler bei der Beschreibung meines Problems, anstatt lösungsorientiert zu antworten. Deine Beiträge sind teilweise so arrogant, dass man den Eindruck gewinnt du willst dich hier einfach nur aufspielen und andere dumm aussehen lassen. Das gehört sich nicht. Die anderen schaffen es doch auch mir enorm weiterzuhelfen, obwohl ich so dumme Fragen habe. Dein Lieblingswort atomar hilft mir hier nicht weiter und erklärt wohl kaum, selbst wenn meine Daten nicht atomar sein sollten, was ich nicht glaube, einen Anstieg von 0,5 auf 14 Sekunden bei so kleinen Datenmengen. Bitte halte dich von meinem Thema einfach fern.


Allen anderen: Vielleicht habt ihr noch einen Tipp für mich oder eine mögliche Erklärung, ich wäre sehr dankbar! *Smilie

 

Hallo!

Ich schrieb allerdings nicht ohne Hintergedanken "Tabelle" statt "Abfrage mit Join". *wink.gif*
Wenn du eine Abfrage mit Join ausführst, entsteht ein viel komplexerer Abfrageplan und du kannst damit nicht prüfen, ob bereits der Zugriff auf die einzelnen Daten das Problem beinhaltet.

Test bitte die Where-Bedingung mit like '1*' nur mit der einen verknüpften Tabelle, ob das dann auch so lange dauert.

Besonders bei Joins in Access-Abfrage muss man eventuell Access etwas helfen, um auf die Datenmenge bezogen einen passenden Ausführungsplan zu erstellen.

Etwas fällt mir noch ein:
Sind die Indizes in der verknüpften Tabelle sichtbar, wenn du sie im Entwurf öffnest? (Anm.: Beim MSSQL-Server werden diese angezeigt, beim MySQL-Server weiß ich das nicht - hier kann vielleicht jemand anders helfen, der MySQL verwendet.)

Allerdings sollte bei nur 500 Datensätzen auch eine Filterung ohne Indizes schnell genug sein - solange der Datenbankserver nicht komplett ausgelastet ist.
Eventuell entsteht durch einen unpassenden Ablaufplan mit beiden Tabellen ein Kreuzprodukt und dann werden aus 500 DS (alle ungefilterten Daten) in der ersten Tabelle und 200 in der anderen Tabelle 100000 DS, die geprüft werden müssen.

mfg
Josef