Czy mogę skonfigurować Mysql do automatycznego partycjonowania?

(Ta odpowiedź jest skierowana do schematu i SELECT.)

Ponieważ przewidujesz miliony wierszy, najpierw chciałbym wskazać kilka ulepszeń w schemacie.

• FLOAT(m,n) jest zwykle „niewłaściwą” rzeczą, ponieważ prowadzi do dwóch zaokrągleń. Użyj zwykłego FLOAT (co wydaje się „właściwe” dla metryk takich jak napięcie) lub użyj DECIMAL(m,n) . FLOAT ma 4 bajty; w podanych przypadkach DECIMAL będzie 3 lub 4 bajty.

• Gdy masz oba INDEX(a) i INDEX(a,b) , to pierwsze jest niepotrzebne, ponieważ drugie może je pokrywać. Masz 3 niepotrzebne KLUCZE. Spowalnia to INSERTs .

• INT(3) -- Czy mówisz „numer 3-cyfrowy”? Jeśli tak, rozważ TINYINT UNSIGNED (wartości 0..255) dla 1 bajtu zamiast INT na 4 bajty. Pozwoli to zaoszczędzić wiele MB miejsca na dysku, a tym samym szybkość. (Zobacz także SMALLINT itp. i SIGNED lub UNSIGNED .)

• Jeśli filename często się powtarza, warto to „znormalizować”. Pozwoliłoby to zaoszczędzić wiele MB.

• Użyj NOT NULL chyba że potrzebujesz NULL za coś.

• AUTO_INCREMENT=690892041 oznacza, że ​​jesteś w około 1/3 drogi do katastrofy z id , co wyniesie około 2 miliardów. Czy używasz id za cokolwiek? Pozbycie się kolumny pozwoliłoby uniknąć problemu; i zmień UNIQUE KEY na PRIMARY KEY . (Jeśli potrzebujesz id , porozmawiajmy dalej).

• ENGINE=MyISAM -- Zamiana ma pewne konsekwencje, zarówno korzystne, jak i niekorzystne. Stół stałby się 2-3 razy większy. „Właściwy” wybór PRIMARY KEY jeszcze bardziej przyspieszy to SELECTs znacznie. (I może, ale nie musi, spowolnić inne SELECTs .)

Uwaga dotycząca SELECTs :Od string i unit_num są stałymi w zapytaniu, ostatnie dwa pola ORDER BY timestamp asc, string asc, unit_num asc są niepotrzebne. Jeśli są istotne z powodów niewidocznych w SELECTs , wtedy moja rada może być niekompletna.

To

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

jest optymalnie obsługiwany przez INDEX(filename, unit_name, string, timestamp) . Kolejność kolumn nie jest ważna z wyjątkiem ten timestamp musi być ostatni . Zmiana układu bieżącego UNIQUE klucz, dajesz optymalny indeks. (Tymczasem żaden z indeksów nie jest zbyt dobry dla tego SELECTs .) Uczynienie z niego PRIMARY KEY a tabela InnoDB sprawi, że będzie to jeszcze szybsze.

Partycjonowanie? Brak przewagi. Nie dla wydajności; nie za nic innego, o czym wspomniałeś. Częstym zastosowaniem partycjonowania jest czyszczenie „starych”. Jeśli zamierzasz to zrobić, porozmawiajmy dalej.

W dużych tabelach najlepiej jest spojrzeć na wszystkie ważne SELECTs jednocześnie, abyśmy nie przyspieszali jednego, jednocześnie burząc prędkość innych. może nawet okazuje się, że partycjonowanie pomaga w tego rodzaju kompromisie.