Lỗi tạo bảng InnoDB: Kích thước hàng quá lớn

Chúng tôi có một số kỹ sư làm phẳng cấu trúc db được chuẩn hóa thành một bảng tạm thời cho mục đích tạo báo cáo. Các cột được chỉ định là TEXT NOT NULL(Tôi biết "tại sao họ làm điều đó?"; Hãy giả sử rằng chúng tôi đang giải quyết vấn đề này).

Chúng tôi sử dụng MySQL 5.1.48 Community RHEL5 với trình cắm InnoDB 1.0.9 trên Linux.

Khi sử dụng MyISAM, chúng tôi không bao giờ gặp phải giới hạn kích thước bảng của cột tối đa hoặc chiều dài hàng tối đa (trong quá trình điều tra, chúng tôi đã đạt giới hạn cột tối đa ở 2598 (2599 gây ra lỗi 1117). Với InnoDB, chúng tôi đang đạt giới hạn. bảng (không chèn dữ liệu) như:

LRI 1118 (42000) ở dòng 1: Kích thước hàng quá lớn. Kích thước hàng tối đa cho loại bảng đã sử dụng, không tính BLOB, là 8126. Bạn phải thay đổi một số cột thành văn bản hoặc BLOB

Tôi đang tìm kiếm câu trả lời cho những điều sau đây:

1. Công thức chi tiết để xác định hạt kích thước hàng khi sử dụng nhiều cột v / v / b / t là gì? Tôi đã thử một vài công thức khác nhau bằng cách sử dụng varchar(N)các cột (trong đó N nằm trong khoảng từ 1 đến 512), bộ ký tự UTF8 (* 3) và nhiều cột như bảng sẽ mất cho đến khi thất bại. Không có combo nào tôi đã thử đưa ra các giá trị khớp với kết quả thử nghiệm thực tế.

2. Tôi phải xem xét "chi phí chung" nào khác khi tính toán kích thước hàng?

3. Tại sao thông báo lỗi thay đổi từ 8126 thành 65535 khi tôi chuyển từ việc tạo bảng có cột varchar (109) sang cột varchar (110)?

Các câu trả lời cho các câu hỏi của bạn rất phức tạp, vì chúng thay đổi theo định dạng tệp InnoDB . Ngày nay, có hai định dạng, được gọi là Antelope và Barracuda.

Tệp vùng bảng trung tâm (ibdata1) luôn ở định dạng Antelope . Nếu bạn sử dụng tệp trên mỗi bảng, bạn có thể làm cho các tệp riêng lẻ sử dụng định dạng Barracuda bằng cách đặt innodb_file_format=Barracudatrong my.cnf.

Điểm cơ bản:

• Một trang 16KB của dữ liệu InnoDB phải chứa ít nhất hai hàng dữ liệu. Ngoài ra, mỗi trang có một tiêu đề và chân trang chứa tổng kiểm tra trang và số thứ tự nhật ký, v.v. Đó là nơi bạn nhận được giới hạn của mình ít hơn 8KB mỗi hàng.

• Các loại dữ liệu có kích thước cố định như INTEGER, DATE, FLOAT, CHAR được lưu trữ trên trang dữ liệu chính này và được tính vào giới hạn kích thước hàng.

• Các loại dữ liệu có kích thước thay đổi như VARCHAR, TEXT, BLOB được lưu trữ trên các trang tràn, vì vậy chúng không được tính hoàn toàn vào giới hạn kích thước hàng. Trong Antelope, tối đa 768 byte của các cột như vậy được lưu trữ trên trang dữ liệu chính ngoài việc được lưu trữ trên trang tràn. Barracuda hỗ trợ định dạng hàng động , do đó, nó chỉ có thể lưu trữ một con trỏ 20 byte trên trang dữ liệu chính.

• Các kiểu dữ liệu có kích thước biến cũng được thêm tiền tố với 1 hoặc nhiều byte để mã hóa độ dài. Và định dạng hàng InnoDB cũng có một loạt các trường bù. Vì vậy, có một cấu trúc nội bộ ít nhiều được ghi lại trong wiki của họ . [EDIT] Liên kết chết - ở đây có vẻ tốt hơn bây giờ.

Barracuda cũng hỗ trợ ROW_FORMAT = COMPRESSED để đạt được hiệu quả lưu trữ cao hơn cho dữ liệu tràn.

Tôi cũng phải nhận xét rằng tôi chưa bao giờ thấy một bảng được thiết kế tốt vượt quá giới hạn kích thước hàng. Đó là một "mùi mã" mạnh mẽ mà bạn đang vi phạm điều kiện nhóm lặp lại của Mẫu thông thường đầu tiên.

Hoàn cảnh của tôi hơi khác. Một trong những yếu tố dữ liệu tôi cần lưu trữ trong mỗi hàng có khả năng rất lớn. (Trường dữ liệu là LONGBLOB cho một tài liệu có thể chứa nhiều hình ảnh nhúng. Cơ sở dữ liệu mẫu của tôi chứa các tài liệu có dung lượng lớn tới 25 - 30 MB, nhưng trong một số trường hợp, các tài liệu này có thể lớn hơn . (Đã thay đổi loại tệp InnoDB thành Barracuda, tăng kích thước tệp nhật ký, đặt định dạng hàng thành COMPRESSED.)

Giải pháp duy nhất tôi thấy có hiệu quả với tôi là quay trở lại MySQL 5.5.x từ MySQL 5.6.x.