Damit die Zeitmessung einen Sinn macht muss ich das ergebnis von dem Query doch auch ausgeben oder?
Nein ....
Der SQL server bereitet deine Daten auf ...
Das heisst , wenn er die Abfrage bekommt, gibts 2 möglichkeiten was er tun koennt.
Er baut ne komplette Struktur im Speicher auf, und gibt dir nen Zeiger, in der SQL-Welt Cursor genannt, zurueck.
Mitt dem Rutschst du dann ueber die daten, wie mit nem Iterator. Der client holt fragt dann also staendig die Daten ab von server ab, je nachdem wie weit du mit der Recordset abfrage weiterkommst.
Das ist ein sogenannter serverside-cursor.
Ob der Server hier optimieren kann, und trotz millionen Zeilen Ergebniss nur paar wenige am anfang holt und spaeter "nachlaed" haengt von der Implementierung ab.
Die meisten server holen aber alles, legens aber nicht unbedingt im speicher ab, sondern temporaer auf der Platte ... und rutschen darauf herum.
Oder aber er streamt quasi den Kompletten Inhalt deiner Abfrage gleich an den Client. Der Client selber haelt die Kompletten Daten im Speicher, solange wie du das Recordset benutzt. und du rutschst darauf herum. client-side cursor.
Das er (der Server) das so machen muss, iss auch klar ....
Wenn deine Abfrage durch ist ... also dein SQL Statement zu ende, iss das eigentlich fuer den Server erledigt ... und dein ergebniss steht fest.
Wenn nachtraeglich jemand die Tabelle aendert, solange du den Recordset auswertest, darf sich Dein Recordset netürlich nicht ändern ... sonst haettest du unerwartete ergebnisse ....
Auf der anderen seite solange du die ergebnisse durcharbeitest, weiss der server ja ned, wenn du damit fertig bist ... ausser du schliesst das recordset, das koennte der Treiber schon übermitteln. Aber solange die Tabelle sperren per default wäre unkooperativ
Es gibt Fälle wo man das machen muss ... das muss man aber selber bauen (Lock Table .... ) , nen "normales Select" sollte das nie selber machen ...
mysql sollte serverside cursor koennen. was der qt treiber nutzt, keine Ahnung.
Was ich mit dem test sehen will :
Wenn deine Abfrage ohne das den Recordset auswertest, schon minuten braucht ... dann brauchst ned am Model Optimieren.
Optimieren kannst recht einfach ueber die limit Geschichte ... um zu sehen was die bringt, sollst das 2te testen ....
Wenn deine Abfrage selber in millisekunden zurueckkommt mit deinem Generischen Test, aber dein View minuten braucht zum anzeigen, dann ist klar das man am Model ansetzen muss ...
Wenn die Abfrage aufm server aber scho minuten braucht ... dann muss man an der Abfrage Optimieren ...
Ich kenn mich mit Mysql ned sooo aus, aber ich hab mal in grauen Vorzeiten viel mit oracle machen mü ... eh dürfen
Ciao ...