Hallo,
die Frage in Kurzform: macht es Sinn, einen zusätzlichen Index auf Spalten zu erzeugen, die schon im Primary Index enthalten sind?
Lange Version:
Ich hab eine Datenbank im iobroker, in der ich u.a. die Daten meiner Wetterstation sammle, und in die ich auch die Daten aus der Cloud des Anbieters der Wetterstation importiert habe. Die Datenbank hat die Spalten:
id - der Messwert (z.B. Außentemperatur)
ts - ein Timestamp
value - der eigentliche Messwert zum jeweiligen Zeitpunkt
Im Primary Index sind id und ts, das hat iobroker bei der Einrichtung so angelegt. Die SELECT Statements für die Visualisierung sehen z.B. so aus:
SELECT ts, val FROM `iobroker`.ts_number WHERE `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts < 1659175200000 AND `iobroker`.ts_number.ts >= 1656583200000 UNION ( SELECT ts, val FROM `iobroker`.ts_number WHERE `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts < 1656583200000 ORDER BY `iobroker`.ts_number.ts DESC LIMIT 1) UNION ( SELECT ts, val FROM `iobroker`.ts_number WHERE `iobroker`.ts_number.id=7 AND `iobroker`.ts_number.ts >= 1659175200000 ORDER BY `iobroker`.ts_number.ts ASC LIMIT 1) ORDER BY ts ASC;
An sich funktioniert das. Abfragen über einen Zeitraum von 2 Jahren dauern ca. 0,4 Sekunden. Allerdings tauchen die Statements im Log für "queries-not-using-indexes" auf, und ich weiß nicht, wieso. Denn wenn ich mir so ein SELECT Statement mit EXPLAIN ansehe, dann steht dort sogar, dass der PRIMARY Key benutzt wird - bis auf das UNION Result am Ende. Ist das der Grund?
Frage ist nun, ob die Abfragen beschleunigt werden können, indem man zusätzliches Indizes einführt, z.B. über die Spalte id oder ts. Ich hab das mal probiert, und die Anzeige in phpmyadmin wird spürbar beschleunigt (vermutlich, weil die ausschließlich nach ts sortiert wird). Die Anzeige im iobroker profitiert allerdings nicht.