... MySQL Datenbanken? Sind mehrere kleine Abfragen schneller, oder ist eine große Abfrage schneller?
Also wenn ich nun das mit dem SqlQuery von Qt mache, und das meine Tabelle id, uid, und name als felder hat, ist dann
- SELECT id, uid, name FROM datenbank
schneller als
- SELECT id FROM datenbank
- SELECT uid FROM datenbank
- SELECT name FROM datenbank
??
Und noch eine evtl. Möglichkeit, ist vielleicht
- SELECT * FROM datenbank
schneller als
- SELECT id, uid, name FROM datenbank
??
Gut, ich könnte hier total falsch sein, mit dem Post, aber evtl. gibt es ja ein paar Leute die von SQL Ahnung haben und bei einem zweiten Forum bin ich eigentlich gar nicht angemeldet.
Vielleicht hat ja jmd. irgendwas, um doch noch ein bischen mehr rauszuholen?
Wie ist das eigentlich mit ...
-
FlorianBecker
- Beiträge: 1213
- Registriert: 2. Dezember 2004 10:54
- Kontaktdaten:
Hi,
von MySQL im speziellen hab ich keine Ahnung, da ich eher der SQL Server Fan bin
Im allgemeinen wuerde ich dir aber von QT`s SqlQuery abraten.
Ich habe zumindest schon Fehler in den TDS7 und ODBC3 Treibern von QT festgestellt und wie mir hier im Forum erzaehlt wurde gibts auch bei den Oracle Treibern Probleme.
Deshalb wuerde ich beim derzeitigen Stand dringend von den QT-SQL Klassen abraten. (...zumindest solange bis ich all meine Fehler zu Trolltech geschickt hab und die dort auch gefixt wurden )
Goos
von MySQL im speziellen hab ich keine Ahnung, da ich eher der SQL Server Fan bin
Im allgemeinen wuerde ich dir aber von QT`s SqlQuery abraten.
Ich habe zumindest schon Fehler in den TDS7 und ODBC3 Treibern von QT festgestellt und wie mir hier im Forum erzaehlt wurde gibts auch bei den Oracle Treibern Probleme.
Deshalb wuerde ich beim derzeitigen Stand dringend von den QT-SQL Klassen abraten. (...zumindest solange bis ich all meine Fehler zu Trolltech geschickt hab und die dort auch gefixt wurden
)Goos
-
FlorianBecker
- Beiträge: 1213
- Registriert: 2. Dezember 2004 10:54
- Kontaktdaten:
Hallo,
also ich arbeite schon seit einigen Jahren immer mit dem SQL Treibern von Qt, bloß nie mit TDS, ODBC + Oracle, was vielleicht auch der Grund dafür ist, das ich noch keinen Fehler hatte bisher. Zumal ich auch nur die Query Klasse benutze und bei der kann es theoratisch keine Probleme geben, weil du nur Querys weiterschickst an die Zuständigen libs und dann die Werte wieder zurückbekommst. Die ganzen Aufspaltungen benutze ich nicht, sind mir ehrlich gesagt auch zu weitreichend. Query reicht mir völlig.
Aber ja, wo du es sagst, ich hatte schonmal nen Fehler mit MySQL, allerdings war da die mysql lib Schuld. Also die Qt SQL Driver benutze ich auf jedenfall, war eigentlich auch nicht mein anliegen, mich davon abzubringen
Außerdem wenn es Fehler gibt, musste einfach nur die Plugins umbauen.
also ich arbeite schon seit einigen Jahren immer mit dem SQL Treibern von Qt, bloß nie mit TDS, ODBC + Oracle, was vielleicht auch der Grund dafür ist, das ich noch keinen Fehler hatte bisher. Zumal ich auch nur die Query Klasse benutze und bei der kann es theoratisch keine Probleme geben, weil du nur Querys weiterschickst an die Zuständigen libs und dann die Werte wieder zurückbekommst. Die ganzen Aufspaltungen benutze ich nicht, sind mir ehrlich gesagt auch zu weitreichend. Query reicht mir völlig.
Aber ja, wo du es sagst, ich hatte schonmal nen Fehler mit MySQL, allerdings war da die mysql lib Schuld. Also die Qt SQL Driver benutze ich auf jedenfall, war eigentlich auch nicht mein anliegen, mich davon abzubringen
Außerdem wenn es Fehler gibt, musste einfach nur die Plugins umbauen.
Hi Florian,
also ich würde mal schätzen, dass
- SELECT id, uid, name FROM datenbank
schneller ist als
- SELECT id FROM datenbank
- SELECT uid FROM datenbank
- SELECT name FROM datenbank
Im ersten Fall hast Du eine Abfrage, in der alle Spalten, bis auf die angegeben drei ausgeblendet werden. Im 2. Fall hast Du jedoch 3 Anfragen, in denen alle Spalten bis auf eine ausgeblendet werden.
Das Ausblenden von Spalten macht denke ich wenig Unterschied, wenn die Anzahl der auszublendenen Spalten nicht besonders groß ist. Sollten jedoch z.B. in einem Fall 100 Spalten übermittelt werden, in einem anderen Fall nur 2, macht das schon einen Unterschied, weil die Daten ja übermittelt werden müssen.
In obigem Beispiel macht die Datenmenge jedoch keinen Unterschied, da die Menge in beiden Fällen am Schluss gleich ist.
Allerdings hast Du im 2. Fall 3 Abfragen, was einen Unterschied machen sollte. Eine Abfrage sollte, wenn sie nicht komplexer als das obige Beispiel ist schneller sein, als 3 Abfragen gleicher Komplexität.
Bei
- SELECT * FROM datenbank
und
- SELECT id, uid, name FROM datenbank
kommt es wohl eher auf die Anzahl der Spalten an, die außer id, uid, name existieren. Wenn es nicht viel mehr Spalten gibt, sollte es keinen Unterschied machen. Selbst wenn etwas mehr Daten übermittelt werden müssten, müssen im 2. Fall die anderen Spalten ausgeblendet werden. Das könnte sich somit wieder relativieren.
Gibt es keine Möglichkeit die Abfragen abzusenden und sich die Zeit der Abarbeitung anzeigen zu lassen? Gibt es keine MySQL Statistik, die sowas ermöglicht?
Gruß
Mike
also ich würde mal schätzen, dass
- SELECT id, uid, name FROM datenbank
schneller ist als
- SELECT id FROM datenbank
- SELECT uid FROM datenbank
- SELECT name FROM datenbank
Im ersten Fall hast Du eine Abfrage, in der alle Spalten, bis auf die angegeben drei ausgeblendet werden. Im 2. Fall hast Du jedoch 3 Anfragen, in denen alle Spalten bis auf eine ausgeblendet werden.
Das Ausblenden von Spalten macht denke ich wenig Unterschied, wenn die Anzahl der auszublendenen Spalten nicht besonders groß ist. Sollten jedoch z.B. in einem Fall 100 Spalten übermittelt werden, in einem anderen Fall nur 2, macht das schon einen Unterschied, weil die Daten ja übermittelt werden müssen.
In obigem Beispiel macht die Datenmenge jedoch keinen Unterschied, da die Menge in beiden Fällen am Schluss gleich ist.
Allerdings hast Du im 2. Fall 3 Abfragen, was einen Unterschied machen sollte. Eine Abfrage sollte, wenn sie nicht komplexer als das obige Beispiel ist schneller sein, als 3 Abfragen gleicher Komplexität.
Bei
- SELECT * FROM datenbank
und
- SELECT id, uid, name FROM datenbank
kommt es wohl eher auf die Anzahl der Spalten an, die außer id, uid, name existieren. Wenn es nicht viel mehr Spalten gibt, sollte es keinen Unterschied machen. Selbst wenn etwas mehr Daten übermittelt werden müssten, müssen im 2. Fall die anderen Spalten ausgeblendet werden. Das könnte sich somit wieder relativieren.
Gibt es keine Möglichkeit die Abfragen abzusenden und sich die Zeit der Abarbeitung anzeigen zu lassen? Gibt es keine MySQL Statistik, die sowas ermöglicht?
Gruß
Mike
-
FlorianBecker
- Beiträge: 1213
- Registriert: 2. Dezember 2004 10:54
- Kontaktdaten:
Hi Mike,
vielen Dank für deine Antwort. Also Statistiken usw. gibt es, viele, daran habe ich ehrlich gesagt vorher nicht gedacht. Außerdem finde ich "goldene Regeln" immer schöner, weil man sich viel Zeit sparen kann, nicht immer alles abzufragen. Ich hatte ehrlich gesagt gehofft, dass ich vielleicht jmd. finden kann, der sich mit der Materie SQL so auskennt um solche Dinge zu sagen wie 100 Zeilen machen eh keinen Unterschied bei der heutigen Rechnerleistung oder nimm die einzelnen Abfragen bei mehr als 10.000 Zeilen usw.
Das Problem mit den Statistiken ist halt immer, was passiert bei 50 Einträgen? Was passiert bei 5T Einträgen und was passiert bei 100T Einträgen usw.
Das größte Problem, was bei mir wohl ist, das ich nach den Typen mit den Indexen, den Fulltext Indexen, Tabellengröße usw. anfangen kann. Vielleicht muss man hier ein wirklich professionelles SQL Struktur Training oder so mal in Betracht ziehen. Ich meine, bei Indexen wird der verbrauchte Speicher erhöht, soweit so gut. Aber wie ist das mit der Länge? Sind MySQL Datenbanken mit 100T - 200T Einträgen noch gesund? Wenn ich 20 Felder habe, macht es einen Unterschied, wenn ich hier nur 10 mit Werten habe und den Rest mit NULL im Gegensatz zu einer Tabelle, die nur 10 Felder hat mit den gleichen Werten? Ich glaube, hier gibt es massive Lücken bei den SQL Dingen.
Ich muss mir immer Strukturen ansehen und finde es manchmal sehr eigenartig, wie man auf solche abstrakten Tabellen kommt. Gut, ich lasse mir das immer erklären, bleibt aber nicht wirklich viel hängen.
Na, jetzt habe ich aber mal alles rausgelassen. Ich würde mich über ein paar poetische Einträge durchaus freuen.
vielen Dank für deine Antwort. Also Statistiken usw. gibt es, viele, daran habe ich ehrlich gesagt vorher nicht gedacht. Außerdem finde ich "goldene Regeln" immer schöner, weil man sich viel Zeit sparen kann, nicht immer alles abzufragen. Ich hatte ehrlich gesagt gehofft, dass ich vielleicht jmd. finden kann, der sich mit der Materie SQL so auskennt um solche Dinge zu sagen wie 100 Zeilen machen eh keinen Unterschied bei der heutigen Rechnerleistung oder nimm die einzelnen Abfragen bei mehr als 10.000 Zeilen usw.
Das Problem mit den Statistiken ist halt immer, was passiert bei 50 Einträgen? Was passiert bei 5T Einträgen und was passiert bei 100T Einträgen usw.
Das größte Problem, was bei mir wohl ist, das ich nach den Typen mit den Indexen, den Fulltext Indexen, Tabellengröße usw. anfangen kann. Vielleicht muss man hier ein wirklich professionelles SQL Struktur Training oder so mal in Betracht ziehen. Ich meine, bei Indexen wird der verbrauchte Speicher erhöht, soweit so gut. Aber wie ist das mit der Länge? Sind MySQL Datenbanken mit 100T - 200T Einträgen noch gesund? Wenn ich 20 Felder habe, macht es einen Unterschied, wenn ich hier nur 10 mit Werten habe und den Rest mit NULL im Gegensatz zu einer Tabelle, die nur 10 Felder hat mit den gleichen Werten? Ich glaube, hier gibt es massive Lücken bei den SQL Dingen.
Ich muss mir immer Strukturen ansehen und finde es manchmal sehr eigenartig, wie man auf solche abstrakten Tabellen kommt. Gut, ich lasse mir das immer erklären, bleibt aber nicht wirklich viel hängen.
Na, jetzt habe ich aber mal alles rausgelassen. Ich würde mich über ein paar poetische Einträge durchaus freuen.
Hi,
hm ich glaube mit goldenen Regeln ist das nicht so einfach bei so einem komplexen Thema. Um es wirklich sicher entscheiden zu können, welche Variante effizienter ist müsste man sich wirklich damit auskennen, wie SQL das ganze intern löst. Gerade dann kann es auch zu Unterschieden zwischen z.B. MySQL und PostgreSQL und Co kommen, weil vielleicht an verschiedenen Stellen verschiedene Implementierungen gewählt wurden, die zu unterschiedlichem Laufzeitverhalten und somit auch entspechenden Geschwindigkeitsunterschieden bei einzelnen Funktionen führen können.
Wenn man sich also nicht genau auskennt und dennoch eine maximale Performance erreichen möchte kommt man wohl ums Nachlernen und zusätzliche Testen nicht drumrum. Bisher kam es bei meinen Anwendungen, die mit SQL arbeiten sollten nicht auf diese letzten Optimierungen an. Sofern sich die Abfragen in akzeptablen Aufwand befanden, war es ok, da nur wenige Queries in einem Zeitabschnitt gesendet und behandelt werden mussten. D.h. solche "schwammigen" Erklärungen, wie oben von mir beschrieben, haben bisher ausgereicht
Gruß
Mike
hm ich glaube mit goldenen Regeln ist das nicht so einfach bei so einem komplexen Thema. Um es wirklich sicher entscheiden zu können, welche Variante effizienter ist müsste man sich wirklich damit auskennen, wie SQL das ganze intern löst. Gerade dann kann es auch zu Unterschieden zwischen z.B. MySQL und PostgreSQL und Co kommen, weil vielleicht an verschiedenen Stellen verschiedene Implementierungen gewählt wurden, die zu unterschiedlichem Laufzeitverhalten und somit auch entspechenden Geschwindigkeitsunterschieden bei einzelnen Funktionen führen können.
Wenn man sich also nicht genau auskennt und dennoch eine maximale Performance erreichen möchte kommt man wohl ums Nachlernen und zusätzliche Testen nicht drumrum. Bisher kam es bei meinen Anwendungen, die mit SQL arbeiten sollten nicht auf diese letzten Optimierungen an. Sofern sich die Abfragen in akzeptablen Aufwand befanden, war es ok, da nur wenige Queries in einem Zeitabschnitt gesendet und behandelt werden mussten. D.h. solche "schwammigen" Erklärungen, wie oben von mir beschrieben, haben bisher ausgereicht
Gruß
Mike
-
FlorianBecker
- Beiträge: 1213
- Registriert: 2. Dezember 2004 10:54
- Kontaktdaten:
Es ist ja nicht so, das ich gar keine Ahnung habe. Bloß leider auch nicht so eine fundierte, das ich mit absoluter Sicherheit und Genauigkeit entscheiden kann, was man tun muss, damit das und das eintritt.
Also mit Tabellen um die 10T Datensätze habe ich ehrlich gesagt auch keine Probleme bisher - ich bin ehrgeizig - reicht mir aber nicht. Mehr als 10T habe ich auch noch nicht in Angriff genommen.
Man kommt also um das Testen, für die Effizienz wohl leider nicht herum. Gut man nehme >5000 Abfragen und fängt einmal an...
Also mit Tabellen um die 10T Datensätze habe ich ehrlich gesagt auch keine Probleme bisher - ich bin ehrgeizig - reicht mir aber nicht. Mehr als 10T habe ich auch noch nicht in Angriff genommen.
Man kommt also um das Testen, für die Effizienz wohl leider nicht herum. Gut man nehme >5000 Abfragen und fängt einmal an...
Hi,
ok 10.000 Datensätze sind ja nicht wirklich viel für eine DB und da braucht man schon viele Abfragen pro Sekunde, damit eine SQL-DB auf einem heutigen Rechner ins Schwitzen kommt.
Aber ich denke, wenn man sich mal eine schöne Tabelle aufbaut, die ruhig etwas komplexer ist und dann mal ein paar Abfragen pro Sekunde reinjagt kann man schon ganz nett damit rumspielen und testen.
Ist nur die Frage: Die Syntax von einfachen SQL Anfragen bei MySQL und Postgre usw. sind ja identisch. Jedoch könnte die Bearbeitungsdauer hinter verschiedenen Datenbanksystemen abweichen. Hat also ein Kunde nun keine MySQL, mit der das Programm getestet wurde, sondern eine PostgreSQL könnte es wieder etwas anders aussehen. Will man das Optimum muss man sich vielleicht auf ein System beschränken und sich darauf spezialisieren.
Gruß
Mike
ok 10.000 Datensätze sind ja nicht wirklich viel für eine DB und da braucht man schon viele Abfragen pro Sekunde, damit eine SQL-DB auf einem heutigen Rechner ins Schwitzen kommt.
Aber ich denke, wenn man sich mal eine schöne Tabelle aufbaut, die ruhig etwas komplexer ist und dann mal ein paar Abfragen pro Sekunde reinjagt kann man schon ganz nett damit rumspielen und testen.
Ist nur die Frage: Die Syntax von einfachen SQL Anfragen bei MySQL und Postgre usw. sind ja identisch. Jedoch könnte die Bearbeitungsdauer hinter verschiedenen Datenbanksystemen abweichen. Hat also ein Kunde nun keine MySQL, mit der das Programm getestet wurde, sondern eine PostgreSQL könnte es wieder etwas anders aussehen. Will man das Optimum muss man sich vielleicht auf ein System beschränken und sich darauf spezialisieren.
Gruß
Mike
-
FlorianBecker
- Beiträge: 1213
- Registriert: 2. Dezember 2004 10:54
- Kontaktdaten:
Ja, das ist wohl wahr, bei den Abfragen geht auch kaum Zeit drauf. Viel mehr Zeit geht immer bei den ganzen Verarbeitungen drauf. Wobei man hier auch einige Dinge einfach in komplexere Abfragen ändern könnte um hier eine gewisse Zeit einzusparen.
Ja, PostgreSQL und MySQL wären hier auch die Systeme über die man Entscheiden müsste. Gut, eine Spezialisierung wäre für mich persönlich doch MySQL.
Mensch, könnte man doch nur auf Abruf ein gewisses Wissen herbeirufen.
Auf jeden Fall hab ich jetzt mal einen einigermaßen wegweisenden Anhaltspunkt erhalten, dank dir.
Ja, PostgreSQL und MySQL wären hier auch die Systeme über die man Entscheiden müsste. Gut, eine Spezialisierung wäre für mich persönlich doch MySQL.
Mensch, könnte man doch nur auf Abruf ein gewisses Wissen herbeirufen.
Auf jeden Fall hab ich jetzt mal einen einigermaßen wegweisenden Anhaltspunkt erhalten, dank dir.