Thay đổi giới hạn cho "Kích thước hàng Mysql quá lớn"

Làm cách nào để thay đổi giới hạn

Kích thước hàng quá lớn (> 8126). Thay đổi một số cột thành TEXT hoặc BLOB hoặc sử dụng ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSEDcó thể hữu ích. Ở định dạng hàng hiện tại, BLOBtiền tố 768 byte được lưu trữ nội tuyến.

Bàn:

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
top_a   varchar(255)    No       
top_b   varchar(255)    No       
top_c   varchar(255)    No       
top_d   varchar(255)    No       
top_e   varchar(255)    No       
top_f   varchar(255)    No       
top_g   varchar(255)    No       
top_h   varchar(255)    No       
top_i   varchar(255)    No       
top_j   varchar(255)    No       
top_title_a varchar(255)    No       
top_title_b varchar(255)    No       
top_title_c varchar(255)    No       
top_title_d varchar(255)    No       
top_title_e varchar(255)    No       
top_title_f varchar(255)    No       
top_title_g varchar(255)    No       
top_title_h varchar(255)    No       
top_title_i varchar(255)    No       
top_title_j varchar(255)    No       
top_desc_a  text    No       
top_desc_b  text    No       
top_desc_c  text    No       
top_desc_d  text    No       
top_desc_e  text    No       
top_desc_f  text    No       
top_desc_g  text    No       
top_desc_h  text    No       
top_desc_i  text    No       
top_desc_j  text    No       
status  int(11) No       
admin_id    int(11) No 

Câu hỏi cũng đã được hỏi trên serverfault .

Bạn có thể muốn xem bài viết này giải thích rất nhiều về kích thước hàng MySQL. Điều quan trọng cần lưu ý là ngay cả khi bạn sử dụng trường TEXT hoặc BLOB, kích thước hàng của bạn vẫn có thể lớn hơn 8K (giới hạn cho InnoDB) vì nó lưu trữ 768 byte đầu tiên cho mỗi trường nội dòng trong trang.

Cách đơn giản nhất để khắc phục điều này là sử dụng định dạng tệp Barracuda với InnoDB. Về cơ bản, điều này sẽ loại bỏ hoàn toàn vấn đề bằng cách chỉ lưu trữ con trỏ 20 byte vào dữ liệu văn bản thay vì lưu trữ 768 byte đầu tiên.

Phương pháp làm việc cho OP ở đó là:

1. Thêm phần sau vào my.cnftệp dưới [mysqld]phần.

   innodb_file_per_table=1
   innodb_file_format = Barracuda
   

2. ALTERbảng để sử dụng ROW_FORMAT=COMPRESSED.

   ALTER TABLE nombre_tabla
       ENGINE=InnoDB
       ROW_FORMAT=COMPRESSED 
       KEY_BLOCK_SIZE=8;
   

Có khả năng những điều trên vẫn không giải quyết được sự cố của bạn. Đó là một lỗi đã biết (và đã được xác minh) với công cụ InnoDB và cách khắc phục tạm thời hiện tại là dự phòng công cụ MyISAM làm bộ nhớ tạm thời. Vì vậy, trong my.cnftệp của bạn :

internal_tmp_disk_storage_engine=MyISAM

Tôi đã gặp phải vấn đề này gần đây và giải quyết nó theo một cách khác. Nếu bạn đang chạy MySQL phiên bản 5.6.20, có một lỗi đã biết trong hệ thống. Xem tài liệu MySQL

Quan trọng Do lỗi # 69477, làm lại ghi nhật ký cho các trường BLOB lớn, được lưu trữ bên ngoài có thể ghi đè lên điểm kiểm tra gần đây nhất. Để giải quyết lỗi này, một bản vá được giới thiệu trong MySQL 5.6.20 giới hạn kích thước của nhật ký làm lại mà BLOB ghi ở 10% kích thước tệp nhật ký làm lại. Do giới hạn này, innodb_log_file_size phải được đặt thành giá trị lớn hơn 10 lần kích thước dữ liệu BLOB lớn nhất được tìm thấy trong các hàng của bảng của bạn cộng với độ dài của các trường có độ dài thay đổi khác (trường loại VARCHAR, VARBINARY và TEXT).

Trong tình huống của tôi, bảng blob vi phạm là khoảng 16MB. Do đó, cách tôi giải quyết nó là thêm một dòng vào my.cnf để đảm bảo rằng tôi có ít nhất 10 lần số tiền đó và sau đó là một số:

innodb_log_file_size = 256M

Đặt các thông tin theo dõi trên tệp my.cnf của bạn và khởi động lại máy chủ mysql.

innodb_strict_mode=0

Nếu bạn có thể chuyển ENGINE và sử dụng MyISAM thay vì InnoDB, điều đó sẽ giúp:

ENGINE=MyISAM

Có hai lưu ý với MyISAM (có thể nói nhiều hơn):

1. Bạn không thể sử dụng giao dịch.
2. Bạn không thể sử dụng các ràng buộc khóa ngoại.

Tôi muốn chia sẻ một câu trả lời tuyệt vời, nó có thể hữu ích. Tín dụng Bill Karwin xem tại đây /dba/6598/innodb-create-table-error-row-size-too-large

Chúng thay đổi theo định dạng tệp InnoDB, hiện tại có 2 định dạng 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 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 = Barracuda trong my.cnf.

Các điểm cơ bản:

1. Một trang dữ liệu InnoDB 16KB phải chứa ít nhất hai hàng dữ liệu. Thêm vào đó, mỗi trang có một đầu trang và một 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 dưới 8KB mỗi hàng.

2. 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.

3. Các kiểu 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 đầy đủ 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 bổ sung. Barracuda hỗ trợ định dạng hàng động, vì vậy nó có thể chỉ lưu trữ một con trỏ 20 byte trên trang dữ liệu chính.

4. Các kiểu dữ liệu có kích thước thay đổi cũng được bắt đầu bằng 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 hiệu số trường. Vì vậy, có một cấu trúc bên trong ít nhiều được ghi lại trong wiki của họ.

Barracuda cũng hỗ trợ ROW_FORMAT = COMPRESSED để tăng thêm hiệu quả lưu trữ 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 rằng bạn đang vi phạm điều kiện nhóm lặp lại của Biểu mẫu thông thường đầu tiên.

Tôi đã gặp vấn đề tương tự, điều này đã giải quyết nó cho tôi:

ALTER TABLE `my_table` ROW_FORMAT=DYNAMIC;

Từ Tài liệu MYSQL :

Định dạng hàng DYNAMIC duy trì hiệu quả của việc lưu trữ toàn bộ hàng trong nút chỉ mục nếu nó phù hợp (cũng như các định dạng COMPACT và REDUNDANT), nhưng định dạng mới này tránh được vấn đề lấp đầy các nút cây B với một số lượng lớn byte dữ liệu cột dài. Định dạng DYNAMIC dựa trên ý tưởng rằng nếu một phần của giá trị dữ liệu dài được lưu trữ ngoài trang, thì việc lưu trữ tất cả giá trị ngoài trang thường là hiệu quả nhất. Với định dạng DYNAMIC, các cột ngắn hơn có khả năng vẫn ở trong nút cây B, giảm thiểu số trang tràn cần thiết cho bất kỳ hàng nhất định nào.

Sau hàng giờ đồng hồ, tôi đã tìm ra giải pháp: chỉ cần chạy SQL sau trong quản trị viên MySQL của bạn để chuyển đổi bảng thành MyISAM:

USE db_name;
ALTER TABLE table_name ENGINE=MYISAM;

Tôi đã gặp sự cố này khi cố gắng khôi phục cơ sở dữ liệu mysql đã sao lưu từ một máy chủ khác. Điều đã giải quyết vấn đề này cho tôi là thêm một số cài đặt nhất định vào my.conf (như trong các câu hỏi ở trên) và thay đổi bổ sung tệp sao lưu sql:

Bước 1: thêm hoặc chỉnh sửa các dòng sau trong my.conf:

innodb_page_size=32K
innodb_file_format=Barracuda
innodb_file_per_table=1

Bước 2 thêm ROW_FORMAT = DYNAMIC vào câu lệnh tạo bảng trong tệp sao lưu sql cho bảng đang gây ra lỗi này:

DROP TABLE IF EXISTS `problematic_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `problematic_table` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
  ...
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 ROW_FORMAT=DYNAMIC;

thay đổi quan trọng ở trên là ROW_FORMAT = DYNAMIC; (không có trong tệp sao lưu orignal sql)

nguồn đã giúp tôi giải quyết vấn đề này: MariaDB và InnoDB MySQL Kích thước hàng quá lớn

Các câu trả lời khác giải quyết câu hỏi được hỏi. Tôi sẽ giải quyết nguyên nhân cơ bản: thiết kế giản đồ kém.

Không trải một mảng trên các cột. Ở đây bạn có 3 * 10 cột sẽ được chuyển thành 10 hàng 3 cột trong một bảng mới (cộng id, v.v.)

MainBàn của bạn sẽ chỉ có

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
status  int(11) No       
admin_id    int(11) No 

Bảng phụ của bạn ( Top) sẽ có

id  int(11) No          -- for joining to Main
seq TINYINT UNSIGNED    -- containing 1..10
img   varchar(255)    No       
title varchar(255)    No       
desc  text    No    
PRIMARY KEY(id, seq)    -- so you can easily find the 10 top_titles

Sẽ có 10 hàng (hoặc ít hơn? Hoặc nhiều hơn?) TopCho mỗi hàng id.

Điều này giúp loại bỏ sự cố ban đầu của bạn và làm sạch lược đồ. (Đây không phải là "bình thường hóa", như đã tranh luận trong một số Nhận xét.)

Do không chuyển sang MyISAM; nó sẽ biến mất.
Đừng lo lắng về ROW_FORMAT.

Bạn sẽ cần phải thay đổi mã của mình để thực hiện JOINvà để xử lý nhiều hàng thay vì nhiều cột.

Tôi đang sử dụng MySQL 5.6 trên AWS RDS. Tôi đã cập nhật phần sau trong nhóm tham số.

innodb_file_per_table=1
innodb_file_format = Barracuda

Tôi đã phải khởi động lại phiên bản DB để các thay đổi nhóm tham số có hiệu lực.

Ngoài ra, ROW_FORMAT = COMPRESSED không được hỗ trợ. Tôi đã sử dụng DYNAMIC như bên dưới và nó hoạt động tốt.

ALTER TABLE nombre_tabla ENGINE=InnoDB ROW_FORMAT=DYNAMIC KEY_BLOCK_SIZE=8

Kích thước hàng tối đa cho bảng InnoDB, áp dụng cho dữ liệu được lưu trữ cục bộ trong trang cơ sở dữ liệu, nhỏ hơn một nửa trang đối với 4KB, 8KB, 16KB và 32KB

Đối với các trang 16kb (mặc định), chúng tôi có thể tính toán:

Slightly less than half a page 8126 / Number of bytes to threshold for overflow 767 = 10.59 fields of 767 bytes maximum

Về cơ bản, bạn có thể tăng tối đa một hàng với:

• 11 trường varchar> 767 ký tự (latin1 = 1 byte cho mỗi ký tự) hoặc
• 11 trường varchar> 255 ký tự (utf-8 trên mysql = 3 byte cho mỗi ký tự).

Hãy nhớ rằng, nó sẽ chỉ tràn sang trang tràn nếu trường có kích thước> 767 byte. Nếu có quá nhiều trường 767 byte, nó sẽ bị phá hủy (vượt quá kích thước hàng_tối đa). Không bình thường với latin1 nhưng rất có thể xảy ra với utf-8 nếu các nhà phát triển không cẩn thận.

Đối với trường hợp này, tôi nghĩ bạn có thể tăng innodb_page_size lên 32kb.

trong my.cnf:

innodb_page_size=32K

Người giới thiệu:

• https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html#row-size-limits
• https://medium.com/@adamhooper/in-mysql-osystem-use-utf8-use-utf8mb4-11761243e434
• https://mariadb.com/kb/en/library/innodb-compact-row-format/#overflow-pages-with-the-compact-row-format
• Cài đặt kích thước trang Innodb

Tôi cũng gặp phải vấn đề tương tự. Tôi giải quyết vấn đề bằng cách thực thi sql sau:

ALTER ${table} ROW_FORMAT=COMPRESSED;

Nhưng, tôi nghĩ bạn nên biết về Row Storage .
Có hai loại cột: cột có độ dài thay đổi (chẳng hạn như VARCHAR, VARBINARY và các loại BLOB và TEXT) và cột có độ dài cố định . Chúng được lưu trữ trong các loại trang khác nhau.

Các cột có độ dài thay đổi là một ngoại lệ đối với quy tắc này. Các cột như BLOB và VARCHAR quá dài để vừa trên trang B-tree được lưu trữ trên các trang đĩa được phân bổ riêng biệt được gọi là trang tràn. Chúng tôi gọi các cột như vậy là cột ngoài trang. Giá trị của các cột này được lưu trữ trong danh sách liên kết riêng của các trang tràn và mỗi cột như vậy có danh sách riêng của một hoặc nhiều trang thừa. Trong một số trường hợp, tất cả hoặc một tiền tố của giá trị cột dài được lưu trữ trong cây B, để tránh lãng phí bộ nhớ và loại bỏ nhu cầu đọc một trang riêng biệt.

và mục đích của việc đặt ROW_FORMAT là khi nào

Khi một bảng được tạo với ROW_FORMAT = DYNAMIC hoặc ROW_FORMAT = COMPRESSED, InnoDB có thể lưu trữ các giá trị cột có độ dài thay đổi dài (đối với các loại VARCHAR, VARBINARY và BLOB và TEXT) hoàn toàn nằm ngoài trang, với bản ghi chỉ mục được phân nhóm chỉ chứa 20- con trỏ byte đến trang tràn.

Muốn biết thêm về Định dạng hàng NĂNG ĐỘNG và NÉN

Nếu điều này xảy ra trên một SELECT có nhiều cột, nguyên nhân có thể là do mysql đang tạo một bảng tạm thời. Nếu bảng này quá lớn không thể chứa vừa trong bộ nhớ, nó sẽ sử dụng định dạng bảng tạm mặc định là InnoDB để lưu trữ trên Đĩa. Trong trường hợp này, các giới hạn kích thước InnoDB sẽ được áp dụng.

Sau đó, bạn có 4 lựa chọn:

1. thay đổi giới hạn kích thước hàng innodb như đã nêu trong một bài đăng khác, yêu cầu khởi động lại máy chủ.
2. thay đổi truy vấn của bạn để bao gồm ít cột hơn hoặc tránh khiến nó tạo ra một bảng tạm thời (tức là loại bỏ các mệnh đề theo thứ tự và giới hạn).
3. thay đổi max_heap_table_size thành lớn để kết quả vừa với bộ nhớ và không cần ghi vào đĩa.

4. thay đổi định dạng bảng tạm mặc định thành MYISAM, đây là những gì tôi đã làm. Thay đổi trong my.cnf:

   internal_tmp_disk_storage_engine=MYISAM

Khởi động lại mysql, truy vấn hoạt động.

Đây là mẹo đơn giản cho bất kỳ ai quan tâm:

Sau khi nâng cấp từ Debian 9 lên Debian 10 với 10.3.17-MariaDB, tôi gặp một số lỗi từ cơ sở dữ liệu Joomla:

[Cảnh báo] InnoDB: Không thể thêm trường fieldtrong bảng database. tablebởi vì sau khi thêm nó, kích thước hàng là 8742 lớn hơn kích thước tối đa cho phép (8126) cho một bản ghi trên trang lá chỉ mục.

Để đề phòng, tôi đặt innodb_default_row_format = DYNAMIC trong /etc/mysql/mariadb.conf.d/50-server.cnf (nó vẫn là mặc định)

Hơn nữa, tôi đã sử dụng phpmyadmin để chạy "Bảng tối ưu hóa" cho tất cả các bảng trong cơ sở dữ liệu Joomla. Tôi nghĩ rằng giải trí bảng được thực hiện bởi phpmyadmin trong quá trình này đã giúp ích. Nếu bạn tình cờ cài đặt phpmyadmin thì chỉ cần vài cú nhấp chuột là xong.