Kích thước của bảng không thực sự là vấn đề, các truy vấn bạn đang chạy trên bảng đó có thể là.
Ví dụ: nếu bạn đang chọn người dùng dựa trên dữ liệu được lưu trữ trong bảng meta người dùng, thì truy vấn đó sẽ không được tối ưu hóa cao, vì meta_value không phải là trường được lập chỉ mục. Trong trường hợp đó, bạn có thể cần thêm các chỉ mục bổ sung hoặc xem xét việc lưu trữ dữ liệu cụ thể đó theo một cách khác, chẳng hạn như với phân loại tùy chỉnh.
Nói chung, những thứ mà bạn lưu trữ dưới dạng meta không bao giờ nên là thứ mà bạn sẽ độc quyền tìm kiếm dựa trên. Điều này áp dụng trên tất cả các bảng meta trong WordPress. Meta được thiết kế chủ yếu để được kéo ra bởi meta_key, không phải bởi meta_value. Phân loại giới hạn các giá trị có thể trong một tập hợp và sắp xếp thông tin khác nhau, vì vậy chúng làm tốt hơn khi "giá trị" được tính như những gì bạn đang chọn.
Lưu ý, việc chọn bởi cả meta_key và meta_value thường ổn, bởi vì myQuery sẽ tối ưu hóa truy vấn dựa trên meta_key trước, giảm lượng dữ liệu để tìm kiếm đến giới hạn có thể quản lý (hy vọng). Nếu ngay cả điều này trở thành vấn đề, bạn có thể "khắc phục" bằng cách thêm chỉ mục mới vào bảng meta với cả meta_key và meta_value trên chỉ mục, tuy nhiên vì meta_value là LONGTEXT, bạn cần giới hạn độ dài của chỉ mục đó ở mức hợp lý, như 20-30 hoặc một cái gì đó, tùy thuộc vào dữ liệu của bạn. Lưu ý rằng chỉ mục này có thể lớn hơn nhiều so với dữ liệu thực tế của bạn và sẽ tăng đáng kể dung lượng lưu trữ cần thiết. Tuy nhiên, nó sẽ nhanh hơn nhiều ở các loại truy vấn đó. Tham khảo ý kiến một DBA đủ điều kiện nếu điều này trở thành một vấn đề thực sự.
Để tham khảo, trên WordPress.org, chúng tôi có khoảng 11 triệu người dùng đã đăng ký. Số lượng meta khác nhau cho mỗi người dùng, có thể tối thiểu 8 hàng mỗi lần và có thể tối đa khoảng 250-ish. Bảng người dùng khoảng 2,5 GB, bảng usermeta khoảng 4 GB. Có vẻ như để chạy ổn, đối với hầu hết các phần, nhưng thỉnh thoảng chúng tôi tìm thấy một số truy vấn kỳ quặc mà chúng tôi phải đi tối ưu hóa.