Tại sao độ dài hàng AVG lại lớn gấp 4 lần như mong đợi?

Có nhiều lý do khiến kích thước hàng trung bình cao.

• Đó là một sự gần đúng. (Tôi nhận thấy rằng nó thường cao 2x-3x.) Trong một trường hợp cực đoan - một hàng trong bảng - nó sẽ yêu cầu 16384 byte mỗi hàng. Đó là một khối InnoDB. Số hàng trong bảng được ước tính . Dung lượng đĩa được sử dụng cho các hàng là chính xác, nhưng hãy xem chi phí chung bên dưới. Kích thước hàng trung bình là thương số của hai hàng đó.

• Chi phí trên mỗi cột - 1 hoặc 2 byte

• Chi phí trên mỗi hàng - 20-30 byte - để xử lý các giao dịch, tìm các hàng trong một khối, v.v.

• Chi phí trên mỗi khối - một số byte trên mỗi khối 16KB

• Chi phí để ném vào một BTree - tối thiểu là khoảng 1/16 khối, tối đa là khoảng một nửa khối, mức trung bình là khoảng 30% sau nhiều lần xóa và / hoặc chèn ngẫu nhiên.

• Chi phí để phân bổ trước các phần không gian đĩa (1MB? 8MB?)

• Khi một bảng phát triển từ việc phù hợp trong một khối, thuật toán bố cục sẽ thay đổi và tỷ lệ chi phí tạm thời tăng đột biến.

• Các hàng đã xóa không trả lại không gian của chúng cho Hệ điều hành, do đó, kích thước tệp không đổi, do đó tăng rõ ràng kích thước hàng.

• Nếu bạn không có PRIMARY KEY rõ ràng hoặc UNIQUE khóa có thể được thăng cấp thành PK, sau đó có một trường 6 byte không thể truy cập (mỗi hàng) cho PK.

• TEXT lớn / BLOB và thậm chí VARCHAR được lưu trữ "ngoài hồ sơ". Điều này làm phức tạp các tính toán rất nhiều. Và nó phụ thuộc vào cái nào trong số 4 ROW_FORMATs bạn đang sử dụng. Trong một số trường hợp, có một "con trỏ" 20 byte cho mỗi ô như vậy.

• FOREIGN KEY các ràng buộc không thêm vào không gian cần thiết, ngoại trừ việc chúng có thể buộc tạo chỉ mục.

• INDEXes , ngoài PRIMARY KEY không được bao gồm trong avg_row_length.

• PRIMARY KEY thường liên quan đến rất ít chi phí trong dữ liệu Được rồi. Quy tắc ngón tay cái đơn giản là chi phí 1% (chính nó trên đầu cột). Chi phí này là các nút không phải của BTree.

• Trong khi giao dịch InnoDB đang bận, mọi hàng đã sửa đổi đều được lưu giữ trong "danh sách lịch sử". Điều này dẫn đến nhiều chi phí hơn.

• (Không liên quan hoàn toàn). COMPRESSED của InnoDB có vấn đề - nó chỉ cho phép nén khoảng 2x, không giống như nén văn bản thông thường là 3x. Tốn một số RAM vì cần có cả dữ liệu nén và không nén trong vùng đệm_bộ đệm cùng một lúc (đối với ít nhất một số khối).

SHOW TABLE STATUS và tìm nạp từ information_schema.TABLES cho cùng một dữ liệu. Có nhiều cách để nhận được một số thông tin chi tiết về độ sâu của B + Tree cho dữ liệu và cho từng bảng.