Posso configurar o Mysql para partição automática?

(Esta resposta é direcionada ao esquema e SELECT.)

Como você antecipa milhões de linhas, primeiro quero destacar algumas melhorias no esquema.

FLOAT(m,n) geralmente é a coisa 'errada' a se fazer porque leva a dois arredondamentos. Ou use FLOAT simples (o que parece 'certo' para métricas como voltagem) ou use DECIMAL(m,n) . FLOAT é 4 bytes; nos casos indicados, DECIMAL seria 3 ou 4 bytes.
Quando você tem ambos INDEX(a) e INDEX(a,b) , a primeira é desnecessária, uma vez que a segunda pode cobrir tal. Você tem 3 chaves desnecessárias. Isso diminui a velocidade de INSERTs .
INT(3) -- Você está dizendo um "número de 3 dígitos"? Se sim, considere TINYINT UNSIGNED (valores 0..255) para 1 byte em vez de INT para 4 bytes. Isso economizará muitos MB de espaço em disco, portanto, velocidade. (Veja também SMALLINT , etc, e SIGNED ou UNSIGNED .)
Se filename é repetido muito, você pode querer "normalizá-lo". Isso economizaria muitos MB.
Use NOT NULL a menos que você precise de NULL para algo.
AUTO_INCREMENT=690892041 implica que você está cerca de 1/3 do caminho para o desastre com id , que chegará a cerca de 2 bilhões. Você usa id para qualquer coisa? Livrar-se da coluna evitaria o problema; e altere a UNIQUE KEY para PRIMARY KEY . (Se você precisar de id , vamos falar mais.)
ENGINE=MyISAM -- A comutação tem algumas ramificações, tanto favoráveis quanto desfavoráveis. A mesa se tornaria 2-3 vezes maior. A escolha 'certa' de PRIMARY KEY aceleraria ainda mais isto SELECT significativamente. (E pode ou não desacelerar outros SELECTs .)

Uma observação sobre o SELECT :Desde string e unit_num são constantes na consulta, os dois últimos campos de ORDER BY timestamp asc, string asc, unit_num asc são desnecessários. Se forem relevantes por motivos não aparentes no SELECT , então meu conselho pode estar incompleto.

este

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

é tratado de forma otimizada por INDEX(filename, unit_name, string, timestamp) . A ordem das colunas não é importante exceto esse timestamp precisa ser último . Reorganizando o UNIQUE atual key, você fornece o índice ideal. (Enquanto isso, nenhum dos índices é muito bom para este SELECT .) Tornando-a a PRIMARY KEY e a tabela InnoDB tornaria ainda mais rápido.

Particionamento? Nenhuma vantagem. Não para desempenho; não para qualquer outra coisa que você mencionou. Um uso comum para particionamento é para limpar 'antigos'. Se você pretende fazer isso, vamos conversar mais.

Em tabelas enormes, é melhor observar todos os SELECTs importantes simultaneamente para não acelerarmos um enquanto demolimos a velocidade de outros. Ele pode até mesmo o particionamento ajuda nesse tipo de troca.