Мога ли да настроя Mysql за автоматично разделяне?

(Този отговор е насочен към схемата и SELECT.)

Тъй като очаквате милиони редове, първо искам да посоча някои подобрения в схемата.

• FLOAT(m,n) обикновено е „погрешното“ нещо, което трябва да направите, защото води до две закръгляния. Използвайте или обикновен FLOAT (което изглежда „правилно“ за показатели като напрежение) или използвайте DECIMAL(m,n) . FLOAT е 4 байта; в посочените случаи, DECIMAL ще бъде 3 или 4 байта.

• Когато имате и двете INDEX(a) и INDEX(a,b) , първото е ненужно, тъй като второто може да покрие такива. Имате 3 ненужни КЛЮЧА. Това забавя INSERTs .

• INT(3) -- „3-цифрено число“ ли казвате? Ако е така, разгледайте TINYINT UNSIGNED (стойности 0..255) за 1 байт вместо INT за 4 байта. Това ще спести много MB дисково пространство, следователно и скорост. (Вижте също SMALLINT и т.н. и SIGNED или UNSIGNED .)

• Ако filename се повтаря много, може да искате да го "нормализирате". Това ще спести много MB.

• Използвайте NOT NULL освен ако не се нуждаете от NULL за нещо.

• AUTO_INCREMENT=690892041 предполага, че сте на около 1/3 от пътя към бедствието с id , което ще достигне около 2 милиарда. Използвате ли id за нещо? Отърването от колоната ще избегне проблема; и променете UNIQUE KEY към PRIMARY KEY . (Ако имате нужда от id , нека поговорим по-нататък.)

• ENGINE=MyISAM -- Смяната има някои разклонения, както благоприятни, така и неблагоприятни. Масата ще стане 2-3 пъти по-голяма. „Правилният“ избор на PRIMARY KEY допълнително ще ускори това SELECTs значително. (И може или не може да забави други SELECTs .)

Бележка за SELECTs :От string и unit_num са константи в заявката, последните две полета на ORDER BY timestamp asc, string asc, unit_num asc са ненужни. Ако са подходящи по причини, които не са очевидни в SELECTs , тогава моят съвет може да е непълен.

Това

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

се обработва оптимално от INDEX(filename, unit_name, string, timestamp) . Редът на колоните не е важен освен това timestamp трябва да е последен . Пренареждане на текущия UNIQUE ключ, вие давате оптималния индекс. (Междувременно нито един от индексите не е много добър за този SELECTs .) Превръщайки го в PRIMARY KEY и таблицата InnoDB ще го направи още по-бързо.

Разделяне? Без предимство. Не за изпълнение; не за друго, което споменахте. Обща употреба на разделянето е за изчистване на „стари“. Ако възнамерявате да направите това, нека поговорим по-нататък.

В огромни таблици е най-добре да разгледате всички важни SELECTs едновременно, така че да не ускоряваме едно, докато унищожаваме скоростта на други. Може дори се оказва, че разделянето помага при този вид компромис.