Tabellen für viele kleine Datensätze optimieren

[Medium]

Södale, ihr habt mich ganz gut davon überzeugen können, dass eine Spaltung in mehrere Tabellen nicht das Gelbe vom Ei ist. Den aktuellen PK, also das autoinc Feld, kann ich hier tatsächlich weg lassen. Hab mir das angewöhnt, weil ich es für unsere Hauptanwendung zwingend brauche, das hier ist aber ausser der Reihe. Der fliegt also schon mal.

Partitioning klingt sehr praktisch, danke auch für das Beispiel als Code. Gelesen habe ich ein wenig drüber, genutzt bisher nicht. Das einzige was mich an der gezeigten Variante stört ist, dass ich quasi jedes Jahr ein "Pflege-Statement" ausführen muss, was mit Sicherheit spätestens nach dem 2. Jahr im Tagesgeschäft unter geht. Kann man es so deichseln, dass mit Beginn eines neuen Jahres automatisch eine neue Partition begonnen wird?

Bezüglich Index: Hier fehlt mir auch noch ein wenig Erfahrung um genau sagen zu können, welche Indizes ich hier wirklich brauche. Einen PK braucht es glaube ich wirklich nicht, aber wenn, dass wäre vdate+valueID ein guter Kandidat. Die kürzesten Intervalle von Einträgen mit derselben valueID sind 1 Minute, also garantiert verschiedene Timestamps.
Bisher habe ich recht naiv immer über die einzelnen Felder einen Index angelegt, die ich nachher in meinen WHERE-Klauseln benutze. Das wäre in diesem Fall vdate und valueID, auch in Kombination. Es wird nachher sicherlich ein Statement der folgenden Struktur genutzt um die Daten zu holen:

SQL-Code:

SELECT
  h.vdate, h.valueID, h.maxValue, h.meanValue, v.valueName 
FROM 
  history h JOIN valueList v 
    ON h.valueID = v.id 
WHERE 
  (h.vdate BETWEEN :sDate AND :eDate) AND 
  (v.valueID IN ({idListe}))

Edit: Der Join macht eigentlich kaum Sinn, da ohnehin bei der Ausgabe nach valueID, vdate sortiert werden sollte. Die Messstellennamen kann ich mir also auch billiger in einem separaten Statement holen und als Überschrift/Legende einsetzen. Die müssen nicht bei jedem Datensatz einzeln bei stehen.

Ist es da besser einen kombinierten Index auf vdate und valueID zu legen, oder jedes Feld seinen eigenen? Oder gar beides? Welche Art von Index eigenet sich hier? (Beide Felder sind für sich genommen non-unique, in Kombi aber unique.) Mein MySQL Tabellen-Tool bietet mir hier die Optionen:
Index Kind: Index, Primary, Unique, Fulltext, Spatial
Index Type: Default, BTree, Hash, RTree
Ich habe mich bisher schämlich wenig damit befasst, welche Index-Arten für welche Fälle geeignet sind

Die angesprochene Trennung von Datum und Uhrzeit wird nicht nötig sein. Wenn, dann werden immer komplette Zeiträume am Stück abgefragt.

Eine separate Tabelle mit Daten zur Anzeige, und Umschaltung bei Zoom klingt zunächst sehr nett, aber ich weiss nicht, ob ich es mir leisten kann auf Dauer mehrere Granularitäten vollständig vorzuhalten. Klar ist, dass ich bei einem Zoom, der pro Pixel im Graphen z.B. 30min entspricht nicht alle minütlichen Werte übers Netzwerk jagen lassen wollen würde. Das Problem habe ich mir bisher nicht genauer angesehen, und hatte gehofft eine Möglichkeit zu finden vielleicht angeben zu können, dass ich nur jeden 2. oder 3. Datensatz einer Ergebnismenge vom Server bekomme. Gibt es sowas?
Wenn nicht, werden redundante Tabellen leider doch wieder interesant, weil vermutlich die letzte Möglichkeit dann.

Danke zwischendurch schon mal für die rege und produktive Teilnahme!