Mysql:nhiều bảng hay một bảng lớn?

Nếu bạn tuân thủ Không, Một hoặc Nhiều nguyên tắc, theo đó hoặc không có thứ đó, một trong số chúng hoặc số lượng không giới hạn, bạn sẽ luôn xây dựng các bảng chuẩn hóa thích hợp để theo dõi những thứ như thế này.

Ví dụ, một lược đồ có thể có:

CREATE TABLE user_attributes (
  id INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  user_id INT NOT NULL,
  attribute_name VARCHAR(255) NOT NULL,
  attribute_value VARCHAR(255),
  UNIQUE INDEX index_user_attributes_name(user_id, attribute_name)
);

Đây là mẫu cửa hàng khóa-giá trị cơ bản mà bạn có thể có nhiều thuộc tính cho mỗi người dùng.

Mặc dù yêu cầu lưu trữ cho việc này cao hơn so với sắp xếp cột cố định với những cái tên khó chịu vĩnh viễn như attribute1 , chi phí đủ nhỏ trong thời đại ổ cứng có kích thước terabyte hiếm khi xảy ra sự cố.

Nói chung, bạn sẽ tạo một bảng duy nhất cho dữ liệu này cho đến khi thời gian chèn trở thành vấn đề. Miễn là quá trình chèn của bạn nhanh, tôi sẽ không lo lắng về điều đó. Tại thời điểm đó, bạn sẽ muốn xem xét một sharding chiến lược chia dữ liệu này thành nhiều bảng với một lược đồ giống hệt nhau, nhưng chỉ khi nó được yêu cầu.

Tôi tưởng tượng rằng con số đó sẽ ở giai đoạn ~ 10-50 triệu hàng, nhưng có thể cao hơn nếu số lượng hoạt động chèn trong bảng này tương đối thấp.

Đừng quên rằng cách tốt nhất để tối ưu hóa hoạt động đọc là sử dụng bộ đệm:Truy vấn cơ sở dữ liệu nhanh nhất là truy vấn bạn không thực hiện. Đối với những thứ như vậy, bạn thường sử dụng một cái gì đó như memcached để lưu trữ kết quả của các lần tìm nạp trước đó và bạn sẽ làm mất hiệu lực điều này khi ghi.

Như thường lệ, điểm chuẩn cho bất kỳ giản đồ được đề xuất nào tại production quy mô.