Bạn chắc chắn sẽ bắt đầu gặp sự cố trên bảng 42 GB đó khi nó không còn phù hợp với bộ nhớ. Trên thực tế, ngay khi nó không còn phù hợp với bộ nhớ nữa, hiệu suất sẽ giảm cực kỳ nhanh chóng. Một cách để kiểm tra là đặt bảng đó trên một máy khác có ít RAM hơn và xem nó hoạt động kém như thế nào.
Điều này là không chính xác. Phân vùng (thông qua tính năng trong MySQL 5.1 hoặc tương tự bằng cách sử dụng bảng MERGE) có thể mang lại lợi ích hiệu suất đáng kể ngay cả khi các bảng nằm trên cùng một ổ đĩa.
Ví dụ:giả sử bạn đang chạy các truy vấn CHỌN trên bảng lớn của mình bằng cách sử dụng một phạm vi ngày. Nếu toàn bộ bảng, truy vấn sẽ bị buộc phải quét qua toàn bộ bảng (và ở kích thước đó, ngay cả việc sử dụng chỉ mục cũng có thể chậm). Ưu điểm của phân vùng là các truy vấn của bạn sẽ chỉ chạy trên các phân vùng thực sự cần thiết. Nếu mỗi phân vùng có kích thước 1 GB và truy vấn của bạn chỉ cần truy cập vào 5 phân vùng để tự hoàn thành thì bảng 5 GB kết hợp sẽ dễ dàng hơn rất nhiều cho MySQL so với phiên bản 42 GB quái vật.
Một điều bạn cần tự hỏi là bạn đang truy vấn dữ liệu như thế nào. Nếu có khả năng các truy vấn của bạn chỉ cần truy cập vào một số phần dữ liệu nhất định (tức là phạm vi ngày hoặc phạm vi ID), thì việc phân vùng theo một số loại sẽ tỏ ra có lợi.
Tôi đã nghe nói rằng vẫn còn một số lỗi với phân vùng MySQL 5.1, đặc biệt liên quan đến việc MySQL chọn đúng khóa. Các bảng MERGE có thể cung cấp chức năng tương tự, mặc dù chúng yêu cầu chi phí cao hơn một chút.
Hy vọng điều đó sẽ giúp ... chúc may mắn!
