[MySQL 4.0] nach zeit gruppieren

[fuzzycontrol]

Hi,

ich habe in meiner Tabelle eine Spalte für DateTime und eine Spalte anzahl.

nun möchte ich in einer Abfrage nach der Zeit gruppieren und summieren, also etwa so

select * from counter.counter
where zeit like '2006-09-25 10:3%'
;

dieses ergebnis soll dann nach einzelnen Minuten gruppiert werden, also
eine Zeile für 10:30
eine Zeile für 10:31

[mrhappiness]

GROUP BY LEFT(datumsspalte, Anzahl Stellen)

[fuzzycontrol]

danke, genau das hab ich gebraucht

[fuzzycontrol]

left() ist leider nicht HQL-kompatibel,

aber dank deiner Hilfe bin ich auf substring() gestossen

[prego]

Ich will jetzt mrhappiness ungern korrigieren, aber mein Ansätz wäre folgender:

SELECT * FROM tab1 GROUP BY YEAR(zeit) 

EDIT:

---

sorry, thema verfehlt *doh*
Dennoch möchte ich anmerken das dir die Datumsfunktionen evtl auch weiter helfen können.

---

[fuzzycontrol]

auch nicht schlecht, damit kann ich dann das machen:
...
group by minute(zeit)
order by zeit

ich bin sehr an mehreren Möglichkeiten der Abfrage interessiert, da die Tabelle sehr gross ist (mehrere Mio Einträge) versuche ich die schnellste rauszufinden

[prego]

Wenn du ein Order by Zeit machst, und zeit ein Feld ist was beim anlegen des Datensatzes erzeugt wird (now() ) dann sortier lieber nach deinem PrimaryKey - das ist schneller.

[wahsaga]

Original geschrieben von prego
Wenn du ein Order by Zeit machst, und zeit ein Feld ist was beim anlegen des Datensatzes erzeugt wird (now() ) dann sortier lieber nach deinem PrimaryKey - das ist schneller.

*seufz*

Seit wann bitte hat ein Primary Key, die Datensatz-ID, irgendeine Sortierungsaufgabe?

[prego]

Hmm, ok - ich will versuchen zu verstehen warum du das sagst.

Folgendes Beispiel:
Ich hab eine Log-Tabelle. Dort werden nach Zeit nun Einträge abgelegt. Dazu gehört ein DateTime-Feld was bei jedem Insert mit now() befüllt wird.

Nun möchte ich die letzten 10 Einträge.

SELECT * FROM tab1 ORDER BY created DESC LIMIT 0,10

soweit ok - wenn ich aber in dieser Tabelle 500k Datensätze habe, ist folgendes schneller:

SELECT * FROM tab1 ORDER BY id DESC LIMIT 0,10

Die id ist fortlaufend, es gibt sie nicht doppelt und sie wächst immer an (primary key, auto increment).

Warum ist es falsch danach zu sortieren?

[wahsaga]

Original geschrieben von prego
Die id ist fortlaufend, es gibt sie nicht doppelt und sie wächst immer an (primary key, auto increment).

Das mag bei deinem Minimalbeispiel vielleicht so sein.

Warum ist es falsch danach zu sortieren?

Weil die ID einzig und allein die Aufgabe hat, einen Datensatz eindeutig zu identifizieren, Punkt.

[prego]

Ok, das nehm ich jetzt erstmal so hin. Wenn du ne Quelle dazu findest wär cool.

Aber wie soll ich den nun mein Beispiel mit der selben Geschwindigkeit deiner Meinung nach lösen, wenn ich nicht "order by id" machen darf?

[fuzzycontrol]

Ich hab mal die Varianten durchgetestet

4,6 Mio Datensätze

die Variante:

- mit left() oder substring() : 5,2 sekunden

- mit group by hour(zeit) order by zeit : 4,68 sekunden

- mit group by hour(zeit) order by id : 4,70 sekunden


Das ist aber keine Statistik, da die Testreihen sehr kurz waren
aber man sieht zumindest, dass substring() länger dauert
und order by id nicht wirklich besser ist als order by zeit

[prego]

Also ich hab hier zB ne User DB. Knapp 100k Einträge, ca 20 Spalten. Ich will die 10 neusten User selecten. (InnoDB)

SELECT * FROM tab1 ORDER BY created DESC LIMIT 0 , 10: 0.5847s

SELECT * FROM tab1 ORDER BY id DESC LIMIT 0 , 10: 0.0789s

Das ist schon ein "größerer" Unterschied...

[wahsaga]

Original geschrieben von prego
Aber wie soll ich den nun mein Beispiel mit der selben Geschwindigkeit deiner Meinung nach lösen, wenn ich nicht "order by id" machen darf?

[ ] Du hast davon gehört, dass man einen Index auf Spalten setzen kann.

[prego]

Ok, ihr hab mich.

Index auf das Feld...

SELECT * FROM tab1 ORDER BY created DESC LIMIT 0 , 10: 0.0838s


Obwohl ich richtigerweise schon mehrere Indeces in der Tabelle gesetzt habe, für andere Sachen, bin ich nicht auf die Idee gekommen meinem DateTime Feld auch noch nen Index zu verpassen... *grmpf*