Kan ik Mysql instellen om automatisch te partitioneren?

(Dit antwoord is gericht op het schema en SELECT.)

Aangezien u miljoenen rijen verwacht, wil ik eerst enkele verbeteringen aan het schema aanstippen.

FLOAT(m,n) is meestal het 'verkeerde' om te doen omdat het tot twee afrondingen leidt. Gebruik gewoon FLOAT (wat 'juist' lijkt voor statistieken zoals spanning) of gebruik DECIMAL(m,n) . FLOAT is 4 bytes; in de gegeven gevallen, DECIMAL zou 3 of 4 bytes zijn.
Wanneer u beide INDEX(a) en INDEX(a,b) , de eerste is niet nodig, omdat de laatste hiervoor kan zorgen. Je hebt 3 onnodige KEY's. Dit vertraagt INSERTs .
INT(3) -- Zegt u een "3-cijferig nummer"? Als dat zo is, overweeg dan TINYINT UNSIGNED (waarden 0..255) voor 1 byte in plaats van INT voor 4 bytes. Dit bespaart veel MB schijfruimte, dus snelheid. (Zie ook SMALLINT , etc, en SIGNED of UNSIGNED .)
Als filename vaak wordt herhaald, wilt u het misschien "normaliseren". Dit zou veel MB besparen.
Gebruik NOT NULL tenzij je NULL nodig hebt voor iets.
AUTO_INCREMENT=690892041 houdt in dat je ongeveer 1/3 van de weg naar een ramp bent met id , die zal uitkomen op ongeveer 2 miljard. Gebruik je id voor alles? Het wegwerken van de kolom zou het probleem voorkomen; en verander de UNIQUE KEY naar PRIMARY KEY . (Als je id wel nodig hebt , laten we verder praten.)
ENGINE=MyISAM -- Overstappen heeft enkele gevolgen, zowel gunstige als ongunstige. De tafel zou 2-3 keer zo groot worden. De 'juiste' keuze van PRIMARY KEY zou dit verder versnellen SELECT aanzienlijk. (En kan wel of niet andere SELECTs vertragen .)

Een opmerking over de SELECT :Sinds string en unit_num zijn constanten in de query, de laatste twee velden van ORDER BY timestamp asc, string asc, unit_num asc zijn onnodig. Als ze relevant zijn om redenen die niet duidelijk zijn in de SELECT , dan is mijn advies mogelijk onvolledig.

Dit

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

wordt optimaal afgehandeld door INDEX(filename, unit_name, string, timestamp) . De volgorde van de kolommen is niet belangrijk behalve dat timestamp moet laatste zijn . De huidige UNIQUE herschikken sleutel, geeft u de optimale index. (Ondertussen is geen van de indexen erg goed voor deze SELECT .) Waardoor het de PRIMARY KEY wordt en de tabel InnoDB zou het nog sneller maken.

Verdeling? Geen voordeel. Niet voor prestaties; niet voor iets anders dat je hebt genoemd. Een veelgebruikt gebruik voor partitionering is voor het opschonen van 'oud'. Als u van plan bent dit te doen, laten we dan verder praten.

In enorme tabellen is het het beste om alle belangrijke SELECTs te bekijken tegelijkertijd, zodat we de ene niet versnellen terwijl we de snelheid van de andere afbreken. Het mag blijkt zelfs dat partitionering helpt bij dit soort afwegingen.