Hi!

Seh ich das richtig: du willst alle Datensätze des letzten Jahres haben, richtig? Warum dann so kompliziert, was spricht gegen:
... WHERE FROM_UNIXTIME(mytimestampspalte, '%Y') = YEAR(NOW())-1
gegen beides spricht, dass ein vorhandener Index auf der Timestampspalte nicht genutzt werden kann. Unter diesem Gesichtspunkt wäre
... WHERE mytimestampspalte BETWEEN <startwert> AND <endwert>
vorzuziehen.

Dazu müsste es aber einer der MySQL-Date/Time-Typen sein und nicht nur ein Integer, der einen Unix-Timestamp darstellt. Alternativ müssten Start- und Endwert ebenfalls als Integer/Unix-Timestamp angegeben werden. Wenn sich das nicht so vereinheitlichen lässt, wäre es zumindest aus Index-Gesichtspunkten sinnvoll, Formeln und Funktionsaufrufe auf konstante Werte zu legen, dann müssen diese Ergebnisse nur einmalig berechnet werden. Legt man sie auf einen Spaltennamen, muss der Ausdruck für jeden Wert neu berechnet werden und ein Index scheidet dann ganz aus. (Eine Ausnahme wären hier funktionale Indexe, die MySQL aber nicht kennt.)

Und - hier bin ich mir allerdings nicht sicher - die Cardinalität dürfte auch noch eine Rolle spielen. Wenn im Index viele verschiedene Werte stehen (sekundenfein aufgelöste Zeitwerte statt nur das Datum), dann dürfte sich eine Indexsuche gegenüber einem Full-Table-Scan nicht viel nehmen. Wenn ich hier richtig liege, und die Uhrzeit keine Rolle spielt, wäre es günstiger, eine DATE-Spalte zu verwenden. Wenn es beim Timestamp bleiben soll, dann wäre es wenigstens angebracht den Zeit-Teil auf 00:00:00 zu setzen.

Der Vorteil des Index wäre lediglich, dass die Werte in ihm schon sortiert liegen, also ein zusammenhängender Bereich sich leichter finden lässt. Wenn ich richtig schlussfolgere, ist bei einer Bereichssuche die Kardinalität des Index weniger bedeutend als die Suche nach einzelnen Werten.

Lo!