Leistungseinbruch bei Abfrage

[Cosmo]

Hallo,
Ich habe ein abfrage die über sechs Tabellen geht (Das DB Design ist nicht von mir damit muss ich leben)

nach dem schema

SELECT bilder.bilderID, textede.titel, texteen.text, textesp.text, textesk.text, texteru.text
FROM bilder, textede, texteen, textesp, textesk, texteru
where bilder.angebot=1
AND bilder.bilderID=textede.bilderID
AND bilder.bilderID=texteen.bilderID
AND bilder.bilderID=textesp.bilderID
AND bilder.bilderID=textesk.bilderID
AND bilder.bilderID=texteru.bilderID

Nicht wundern aber das funktioniert sogar :D das Problem ist nur das mit der letzten "AND" Bedingung die Performance völlig einbricht .
Bis zur vierten ist eigentlich alles i.o. gibt es da ein Limit für "AND" Bedingungen ist der Server zu lahm oder schafft MySQL nicht mehr.

Alternativ habe ich die Abfrage aufgesplittet und alles in mehrdimensionale Arrays gestopft, das lässt jedenfalls keine Wünsche hinsichtlich der Performance offen.

Nur Mein Script ist mal wieder explodiert
:D

[elrond]

mein tip ist, wenns tatsächlich an der letzten where Bedingung liegt ("bilder.bilderID=texteru.bilderID") , dass der Tabelle texteru ein Index auf der Spalte bilderID fehlt.

[Christoph]

Wenn Du PostgreSQL benutzt, dann kannst Du mit


EXPLAIN SELECT ...

dir den Abfrageplan ansehen. Insbesondere siehst Du dann, ob Indizes genutzt werden oder nicht ("Seq Scan" steht für "sequential scan", also die Nichtnutzung von Indizes). Wenn Du bei Postgres einen Index anlegst, dann musst Du auch ANALYZE auf die Tabelle ausführen (da gibt's auch irgendwas im ~/contrib Zweig von 7.4, das das automatisch bei Bedarf macht).

[Cosmo]

Wenn Du PostgreSQL benutzt, dann kannst Du mit

Leider nicht

Das Problem eines schlechten DB Designs kommt leider hier immer mehr zum tragen, wie sich herrausstellte ist die Verwaltung der Einträge grottenschlecht und es ist mit potenziellen fehlern in der Bedienung zu rechnen, so daß Datensätze in den einzelnen Tabellen uneinheitlich gelöscht werden können.
Das würde zu einem aushebeln meiner "sechsTabellenAbfrage" führen, ergebnis nada nichts null.
Deswegen Arbeite ich jetzt weiter mit Arrays incl. Fehlerausgabe in der Übersicht ob die Tabellen einheitlich sind und wo der Fehler auftritt.

Glück hat immer der, der sagen kann "nach mir die Sinnflut", dafür kann ich immer besser Schwimmen :p

[elrond]

Original geschrieben von Cosmo
Das Problem eines schlechten DB Designs kommt leider hier immer mehr zum tragen, ...

:( ich hoffe, Dir hilft unser Beileid...
Alles steht und fällt eben mit einem vernünftigen DB-Design. Ich habe grade mal wieder mit Navision Finacials zu tun. Dort wird Performace ausschließlich über Hardware generiert. Wenn ich mir die DB ansehe, weiß ich auch warum das notwendig ist :mad: :mad:

[Christoph]

Das Problem eines schlechten DB Designs kommt leider hier immer mehr zum tragen, wie sich herrausstellte ist die Verwaltung der Einträge grottenschlecht und es ist mit potenziellen fehlern in der Bedienung zu rechnen, so daß Datensätze in den einzelnen Tabellen uneinheitlich gelöscht werden können.

Das sollte sich doch mit Foreign Key Constraints (ON DELETE CASCADE bzw. ON DELETE SET NULL) auch nachträglich noch beheben lassen:

ALTER TABLE ADD COMNSTRAINT ...

[Pingu]

Hi Cosmo,

da Du ja scheinbar mySQL hast, hast Du Dir schon mal die Doku angesehen und die dort vorgeschlagenen Optimierungshinweise (http://www.mysql.com/doc/de/Query_Speed.html) beherzigt?

Pingu

[Cosmo]

Du ja scheinbar mySQL hast

Richtig und ich entschuldige mich hiermit in aller Form für meine unsaubere Frageformulierung:)

Danke das mit den Optimierungshinweisen werd ich mir nochmal in Ruhe ansehen!

Danke auch für die anderen Tips mein MySQL wissen ist offensichtlich noch etwas bescheiden :rolleyes:

Das Problem ist aber nicht nur auf die DB beschränkt wie gesagt ist die DB struktur bescheiden und die vorhandenen PHP Tools naja ich sag mal zusammengefrickelt.

Ich musste das Problem für meinen Verwaltungsteil mehr oder weniger von hinten aufrollen.
(u.a. Fehlerhandling wobei die potenziellen Fehler von vornherein auszuschliessen gewesen wären)

Auf jeden fall schonmal Danke für die Anregungen.

Letzte Frage:
wann bietet mir eigentlich PostgreSQL einen richtigen Vorteil gegenüber MySQL?

[Christoph]

wann bietet mir eigentlich PostgreSQL einen richtigen Vorteil gegenüber MySQL?

Um nur ein paar Punkte zu nennen:

a) Volle SQL2-Unterstützung
MySQL hat einen eigenen, zum SQL-Standard an vielen Stellen inkompatiblen SQL Dialekt.
Für viele wichtige SQL-Features muss man in MySQL komplizierte Workarounds stricken
=> komplexe Abfragen sind in MySQL schwierig zu realisieren und auch deutlich langsamer
(andererseits sind einfache Abfragen aber oft schneller in MySQL)

b) Integrity Constraints (Foreign Keys mit allem Schnickschnack (z.B. ON UPDATE CASCADE))
=> die Integrität der Daten hängt nicht mehr davon ab, ob der Anwender (oder der Anwendungsprogrammierer) aufpasst

c) Multi-Version Concurrency Control für Transaktionen
=> hohe Nebenläufigkeit von Transaktionen. Überhaupt ist die Transaktionsunterstützung einer der Hauptgründe überhaupt eine Datenbank statt einfacher Dateien zu verwenden.

d) Stored Procedures und Trigger
=> Verlagerung von Applikationslogik auf den Server führt zu deutlichem Performancegewinn und einfacherer Wartung der Clientanwendungen

Wenn man -wie ich- von Oracle kommt, dann hat man bei PostgreSQL das Gefühl eine "richtige" Datenbank zu verwenden, bei MySQL irgendwie nicht. Für kleinere Anwendungen ist MySQL aber durhcaus hinreichend. Der Hauptvorteil von MySQL besteht darin, dass man es auch ohne Datenbankkenntnisse ganz gut verwenden kann (das versuche man mal mit Oracle...)