Posso configurare Mysql per la partizione automatica?

(Questa risposta è diretta allo schema e SELECT.)

Dato che prevedi milioni di righe, prima di tutto voglio segnalare alcuni miglioramenti allo schema.

FLOAT(m,n) di solito è la cosa "sbagliata" da fare perché porta a due arrotondamenti. O usa il semplice FLOAT (che sembra "giusto" per metriche come la tensione) o usa DECIMAL(m,n) . FLOAT è 4 byte; nei casi indicati, DECIMAL sarebbero 3 o 4 byte.
Quando hai entrambi INDEX(a) e INDEX(a,b) , il primo non è necessario in quanto il secondo può coprirlo. Hai 3 chiavi non necessarie. Questo rallenta INSERTs .
INT(3) -- Stai dicendo un "numero a 3 cifre"? In tal caso, considera TINYINT UNSIGNED (valori 0..255) per 1 byte invece di INT per 4 byte. Ciò farà risparmiare molti MB di spazio su disco, quindi velocità. (Vedi anche SMALLINT , ecc e SIGNED o UNSIGNED .)
Se filename viene ripetuto molto, potresti volerlo "normalizzare". Ciò farebbe risparmiare molti MB.
Usa NOT NULL a meno che tu non abbia bisogno di NULL per qualcosa.
AUTO_INCREMENT=690892041 implica che sei a circa 1/3 della strada per il disastro con id , che raggiungerà il massimo a circa 2 miliardi. Utilizzi id per qualsiasi cosa? Sbarazzarsi della colonna eviterebbe il problema; e cambia la UNIQUE KEY a PRIMARY KEY . (Se hai bisogno di id , parliamo ulteriormente.)
ENGINE=MyISAM -- Il cambio ha alcune ramificazioni, sia favorevoli che sfavorevoli. Il tavolo diventerebbe 2-3 volte più grande. La scelta "giusta" di PRIMARY KEY accelererebbe ulteriormente questo SELECTs in modo significativo. (E può o meno rallentare altri SELECTs .)

Una nota sul SELECTs :Poiché string e unit_num sono costanti nella query, gli ultimi due campi di ORDER BY timestamp asc, string asc, unit_num asc sono inutili. Se sono rilevanti per ragioni non evidenti in SELECTs , allora il mio consiglio potrebbe essere incompleto.

Questo

WHERE filename = 'foobar'
  AND unit_num='40'
  AND string='2' 
  AND timestamp >= ...

è gestito in modo ottimale da INDEX(filename, unit_name, string, timestamp) . L'ordine delle colonne non è importante tranne quel timestamp deve essere ultimo . Riorganizzare l'attuale UNIQUE chiave, ti dai l'indice ottimale. (Nel frattempo, nessuno degli indici è molto buono per questo SELECTs .) Rendendolo il PRIMARY KEY e il tavolo InnoDB lo renderebbe ancora più veloce.

Partizionamento? Nessun vantaggio. Non per le prestazioni; non per nient'altro che hai menzionato. Un uso comune per il partizionamento è per eliminare il "vecchio". Se hai intenzione di farlo, parliamo ulteriormente.

Nelle tabelle enormi è meglio guardare tutti i SELECTs importanti simultaneamente in modo da non accelerarne uno mentre demoliamo la velocità degli altri. può anche scoprire che il partizionamento aiuta in questo tipo di compromesso.