Ok, el optimizador de consultas parece tener algunos problemas con mi respuesta anterior con tablas grandes. Pruebe esta solución en su lugar, funciona con subconsultas dependientes:
SELECT DATE_FORMAT(timeTable.minuteTime, '%Y-%m-%d %k:%i') time,
T2.temp temp,
S2.solids solids,
P2.Ph Ph
FROM
(
SELECT minuteTime.minuteTime minuteTime,
( SELECT MAX(time) FROM temperature WHERE time <= minuteTime.minuteTime AND time >= NOW() - INTERVAL 1 HOUR) tempTime,
( SELECT MAX(time) FROM ph WHERE time <= minuteTime.minuteTime AND time >= NOW() - INTERVAL 1 HOUR) phTime,
( SELECT MAX(time) FROM solids WHERE time <= minuteTime.minuteTime AND time >= NOW() - INTERVAL 1 HOUR) solidsTime
FROM
(
SELECT time + INTERVAL 59 - SECOND( time ) SECOND minuteTime
FROM Ph
WHERE time >= NOW() - INTERVAL 1 HOUR AND time <= NOW()
UNION SELECT time + INTERVAL 59 - SECOND( time ) SECOND
FROM solids
WHERE time >= NOW() - INTERVAL 1 HOUR AND time <= NOW()
UNION SELECT time + INTERVAL 59 - SECOND( time ) SECOND
FROM temperature
WHERE time >= NOW() - INTERVAL 1 HOUR AND time <= NOW()
GROUP BY 1
) minuteTime
) timeTable
LEFT JOIN temperature T2 ON T2.time = timeTable.tempTime
LEFT JOIN solids S2 ON S2.time = timeTable.solidsTime
LEFT JOIN ph P2 ON P2.time = timeTable.phTime
ORDER BY minuteTime ASC
He configurado las tres tablas con alrededor de 800 000 filas de datos de prueba, cada una. En MySQL 5.5.30, la consulta anterior se ejecuta en unos 3,5 segundos y devuelve 61 filas de resultados. Pero absolutamente debe tener índices en cada una de las columnas de tiempo:
ALTER TABLE `ph` ADD INDEX ( `time` ) ;
ALTER TABLE `solids` ADD INDEX ( `time` ) ;
ALTER TABLE `temperature` ADD INDEX ( `time` ) ;
De lo contrario, la consulta no terminará. Creo que ninguna consulta que maneje esta cantidad de datos lo hará.