Tôi có thể thiết lập Mysql để tự động phân vùng không?

(Câu trả lời này hướng đến lược đồ và CHỌN.)

Vì bạn dự đoán hàng triệu hàng, trước tiên tôi muốn chỉ ra một số cải tiến đối với giản đồ.

FLOAT(m,n) thường là điều 'sai' phải làm vì nó dẫn đến hai lần làm tròn. Sử dụng FLOAT đơn giản (có vẻ 'đúng' đối với các số liệu như điện áp) hoặc sử dụng DECIMAL(m,n) . FLOAT là 4 byte; trong các trường hợp đã cho, DECIMAL sẽ là 3 hoặc 4 byte.
Khi bạn có cả INDEX(a) và INDEX(a,b) , cái trước là không cần thiết vì cái sau có thể bao gồm như vậy. Bạn có 3 chìa khóa không cần thiết. Điều này làm chậm INSERTs .
INT(3) - Bạn đang nói "số có 3 chữ số"? Nếu vậy, hãy xem xét TINYINT UNSIGNED (giá trị 0..255) cho 1 byte thay vì INT cho 4 byte. Điều này sẽ tiết kiệm nhiều MB dung lượng ổ đĩa, do đó tăng tốc độ. (Xem thêm SMALLINT , v.v. và SIGNED hoặc UNSIGNED .)
Nếu filename được lặp lại rất nhiều, bạn có thể muốn "bình thường hóa" nó. Điều này sẽ tiết kiệm nhiều MB.
Sử dụng NOT NULL trừ khi bạn cần NULL cho một cái gì đó.
AUTO_INCREMENT=690892041 ngụ ý rằng bạn đang đi khoảng 1/3 chặng đường dẫn đến thảm họa với id , sẽ đạt khoảng 2 tỷ. Bạn có sử dụng id để làm gì? Loại bỏ cột sẽ tránh được vấn đề; và thay đổi UNIQUE KEY tới PRIMARY KEY . (Nếu bạn cần id , chúng ta hãy nói chuyện xa hơn.)
ENGINE=MyISAM - Chuyển đổi có một số phân nhánh, cả thuận lợi và không thuận lợi. Chiếc bàn sẽ trở nên lớn gấp 2-3 lần. Lựa chọn 'đúng' của PRIMARY KEY sẽ tăng tốc hơn nữa điều này SELECT đáng kể. (Và có thể làm chậm hoặc không làm chậm các SELECT khác .)

Lưu ý về SELECT :Kể từ string và unit_num là các hằng số trong truy vấn, hai trường cuối cùng của ORDER BY timestamp asc, string asc, unit_num asc là không cần thiết. Nếu chúng có liên quan vì những lý do không rõ ràng trong SELECT , thì lời khuyên của tôi có thể không đầy đủ.

Điều này

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

được xử lý tối ưu bởi INDEX(filename, unit_name, string, timestamp) . Thứ tự của các cột không quan trọng ngoại trừ timestamp đó cần phải là cuối cùng . Sắp xếp lại UNIQUE hiện tại chính, bạn cung cấp cho bạn chỉ số tối ưu. (Trong khi đó, không có chỉ mục nào là rất tốt cho SELECT này .) Đặt nó thành PRIMARY KEY và bảng InnoDB sẽ làm cho nó nhanh hơn nữa.

Phân vùng? Không có lợi thế. Không phải cho hiệu suất; không phải cho bất cứ điều gì khác bạn đã đề cập. Một cách sử dụng phổ biến để phân vùng là xóa 'cũ'. Nếu bạn có ý định làm như vậy, hãy nói chuyện thêm.

Trong các bảng lớn, tốt nhất là xem tất cả các SELECTs quan trọng đồng thời để chúng tôi không tăng tốc một trong khi phá hủy tốc độ của những người khác. Nó có thể thậm chí hóa ra rằng việc phân vùng sẽ giúp ích cho sự cân bằng này.