MySQL 5.7 - Komplexe View

[Ben2003]

Hallo,

im Umgang mit Indexierung & Co. bin ich nicht so bewandert.

Bisher wurden fast alle Views abhängig vom Umfang der Daten relativ performant ausgeführt.

Nun muss allerdings in einer View auf viele Tabellen und einige weitere Views zurückgegriffen werden.

Beim Ausführen wird immer ein TimeOut gemeldet, egal wie auch die Wartezeit eingestellt wird.

Zu meinem Anliegen:

Beruflich hatte ich viel mit MS SQL zu tun gehabt. Da gibt es eine Funktion "Ablaufplan erstellen" oder so ähnlich, da nach der Ausführung genau angezeigt hat, wie viele Datensätze von allen Tabellen und Views gelesen wurden, welche Indexe dabei verwendet wurden, und wie lange es gedauert hat, diese auszuwerten. Zusätzlich wurden alle Tabellen und Views ansprechend visuell angezeigt.
Gibt es etwas vergleichbares auch für MySQL?

Für MySQL nutze ich das Tool "dbForge Studio für MySQL". In dem Tool kann auch eine Ablaufdiagramm erstellt werden, jedoch werden die Ergebnisse nur in Form einer Tabelle angezeigt. Hier kann weder angezeigt werden, welche Indexe verwendet wurden, noch wie viele Datensätze im einzelnen ausgelesen wurden.
Erst auf der Grundlage dieser Informationen kann man doch erst sehen, ob irgendwo ein Index fehlt oder ein bestehendes lediglich angepasst werden muss.

Mit dem Tool "dbForge Studio für MySQL" bin ich im Allgemeinen ganz zufrieden, da die Bedienung mehr Visuell unterstützend aufgebaut ist. Ganz hilfreich ist die Autokorrektur-Funktion Durch die während des Tippens schon die Objektnamen und Felder angezeigt werden, die in der Tabelle oder View zur Verfügung stehen. Auch bei Joins-Verbindungen werden die vorhandenen Beziehungen angeboten. Da braucht man nicht mehr groß überlegen, welche Beziehung nun von Tabelle A ausgehen.

Wie macht Ihr denn das, wenn Ihr am Entwickeln einer Datenbank seid.
Erstellt Ihr dann aufgrund Eurer Erfahrungen bzw. aus dem Bauchgefühl heraus Indexe?

 

[akretschmer]

Wie macht Ihr denn das, wenn Ihr am Entwickeln einer Datenbank seid.

Wir verwenden kein MySQL.

 

[Ben2003]

Hallo,

Wir verwenden kein MySQL.
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Demnach verwendet Ihr PostgreSQL? Von PostgreSQL habe ich nur vom Namen her hier un da was gelesen, aber mich nicht damit näher befasst. Ist es denn ähnlich aufgebaut wie eine Relationale Datenbank?

 

[akretschmer]

Ja, als die wohl größte (und beste) Supportfirma für PostgreSQL verwenden wir das auch hin und wieder ;-) Und ja: das ist eine relationale Datenbank. Unter anderem, weil es kann viel, viel mehr als nur das.

 

[Dukel]

Egal ob man MySql oder Postgresql nutzt. Indexe erstellt man nicht aus dem Bauch heraus, sondern wegen der Anforderungen.

 

[akretschmer]

Genau. Und weil es im Eröffnungspost um Indexe und "Ablaufpläne" und dann um PostgreSQL ging: das hat ein EXPLAIN, was die Ablaufpläne anzeigt. Kostenbasiert und mit vielen Informationen. Und man kann auch in die Pläne eingreifen etc. Nicht zu vergleichen mit dem,was MySQL bietet.

 

[dabadepdu]

Unabhängig vom System erstellt man einen Index nicht auf Verdacht. Sondern
für PK (meist automatisch)
für FK (meist automatisch)
dann naheliegend für bspw. Suchfelder (Name, Straße, Artikel ..)
Das ist meist der Anfang. Mehr nicht.

Dann wird man sehen, wo der Schuh drückt. Um mal zum Titel des Threads zu kommen. Nach den Vorgaben oben würde man auch in einem komplexen View oder Select Statement alle Key Felder bereits indiziert haben -auf denen man ja normalerweise joint- und wäre theoretisch schon fertig.

In der Praxis kann man ab hier eigentlich kaum allgemeine Ratschläge geben. Performancemangel bemerkt man ja mehr oder weniger automatisch. Dem geht man dann gezielt nach. Und zwar mit einem Tool, was die Ausführungspläne der Abfrage darstellt. Hier wird es bei verschiedenen Herstellern sehr bunt, denn jenseits des logischen Datenzugriff und ANSI Standards, sind Fragen wie Indizierung, Speicherort und -Verfahren, Optimierungsverfahren, Statistiken usw. kaum oder gar nicht standardisiert. Wenn doch, dann am ehesten noch durch mathematische oder logische Gegebenheiten mit Grundsatzcharakter. Damit sind dann bestimmte Indextypen bspw. doch Standard.

Also

• "EXPLAIN" ist Dein Freund, es zeigt, was die DB Engine tatsächlich abfragt (z.b. ob ein Index gar überhaupt berücksichtigt wird)

• ein gutes, sachgerechtes Datenmodell ebenso (dazu gehört einige Erfahrung und vielleicht auch die Erkenntnis, dass eine perfekte Normalisierung nicht immer zum Ziel führt, verbunden mit der Kenntnis, wie man Konsistenz trotz Denormalisierung bewahrt)
  
• ein Index ist gut, viele Indices nicht unbedingt!
• ein Indextyp ist gut, viele Indextypen noch besser! Weil sie sehr spezifisch nach Problemsituation eingesetzt werden können (wenn man sie im Repertoire hat)
  
• diverse Sprachfeatures, die jenseits der allgemeinen Basics einfach enorme Vereinfachung bringen können (das Gegenteil von Komplexität)

Und da noch mal zur Theorie: Komplexität entsteht nicht zwangsläufig durch ein komplexes Datenmodell oder einen komplizierten Report. Sie entsteht u.U. durch die schwachen Möglichkeiten in der Abfrage. In der Praxis begegnet einem das häufig als "Workaround". Das freilich nur, wenn der Non-Workaround einem als Normalität bekannt ist. Ein kleines Beispiel wären Temp-Tables. Wenn nichts mehr geht, "dann nimm eine Temptable, mach einen Insert mit der Query, dann sortier das und lösch alle mit XY und davon machst Du dann einfach den Join, den eigentlich Du wolltest". Für viele Entwickler sind solche Dinge Alltag, entweder in der Praxis oder als Ratschlag, wenn sie in einem Forum nachfragen. Hier noch mal der Schlenker zur Frage: Wie gut funktionieren nun Views zusammen mit Temp Tables? Nur zur Klarheit, dieses Problem spricht nicht gegen den Einsatz von Views, Views sind ein vielfach unterschätztes Feature. Dieses Beispiel zeigt, dass es Dinge gibt, deren Einsatz ein "breaking change" ist, natürlich überhaupt nicht positiv zu sehen. Temp Tables gehören oft dazu.
Davon könnte man nun stundenlang schreiben. Etwas näher an Deiner Frage wäre z.B. der Punkt, welche Indizes werden von der Engine überhaupt gemeinsam genutzt (ich glaub dazu gab's hier neulich auch einen Thread)? In dem Sinne, dass viele Indizes nicht beliebig kombinierbar sind oder nicht zusammen mit bestimmten Where Kriterien funktionieren.

Da Deine Frage im mySQL Bereich steht, eine einfache Antwort: Du hast nur recht wenig Möglichkeiten, es irgendwie zu machen. Zeig ein konkretes Problem und man kann dem nachgehen.