Kan jeg sætte Mysql op til automatisk partitionering?

(Dette svar er rettet mod skemaet og SELECT.)

Da du forventer millioner af rækker, vil jeg først påpege nogle forbedringer af skemaet.

FLOAT(m,n) er normalt den 'forkerte' ting at gøre, fordi det fører til to afrundinger. Brug enten almindelig FLOAT (hvilket virker "rigtigt" for metrik som spænding) eller brug DECIMAL(m,n) . FLOAT er 4 bytes; i de angivne tilfælde DECIMAL ville være 3 eller 4 bytes.
Når du har både INDEX(a) og INDEX(a,b) , førstnævnte er unødvendigt, da sidstnævnte kan dække for sådanne. Du har 3 unødvendige NØGLER. Dette sænker INSERTs .
INT(3) -- Siger du et "3-cifret nummer"? Hvis ja, overvej TINYINT UNSIGNED (værdier 0..255) for 1 byte i stedet for INT for 4 bytes. Dette vil spare mange MB diskplads, deraf hastighed. (Se også SMALLINT osv. og SIGNED eller UNSIGNED .)
Hvis filename gentages meget, vil du måske gerne "normalisere" det. Dette ville spare mange MB.
Brug NOT NULL medmindre du har brug for NULL for noget.
AUTO_INCREMENT=690892041 antyder, at du er omkring 1/3 af vejen til katastrofe med id , som vil toppe med omkring 2 mia. Bruger du id for alt? At slippe af med kolonnen ville undgå problemet; og ændre den UNIQUE KEY til PRIMARY KEY . (Hvis du har brug for id , lad os tale videre.)
ENGINE=MyISAM -- Skift har nogle konsekvenser, både gunstige og ugunstige. Bordet ville blive 2-3 gange så stort. Det 'rigtige' valg af PRIMARY KEY ville fremskynde dette yderligere SELECT væsentligt. (Og kan eller kan ikke bremse andre SELECTs .)

En bemærkning om SELECT :Siden string og unit_num er konstanter i forespørgslen, de sidste to felter i ORDER BY timestamp asc, string asc, unit_num asc er unødvendige. Hvis de er relevante af årsager, der ikke fremgår af SELECT , så er mit råd måske ufuldstændigt.

Dette

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

håndteres optimalt af INDEX(filename, unit_name, string, timestamp) . Rækkefølgen af kolonnerne er ikke vigtig undtagen det timestamp skal være sidste . Omarrangerer den nuværende UNIQUE nøgle, giver du dig det optimale indeks. (I mellemtiden er ingen af indekserne særlig gode til denne SELECT .) Gør det til PRIMARY KEY og tabellen InnoDB ville gøre det endnu hurtigere.

Opdeling? Ingen fordel. Ikke for ydeevne; ikke for noget andet du har nævnt. En almindelig anvendelse til partitionering er at rense 'gamle'. Hvis du har til hensigt at gøre sådan, lad os tale videre.

I store tabeller er det bedst at se på alle de vigtige SELECTs samtidig, så vi ikke fremskynder én, mens vi ødelægger farten på andre. Det kan endda vise sig, at partitionering hjælper i denne form for afvejning.