124 votes

Modification de la limite pour "Mysql Row size too large".

Comment puis-je modifier la limite

La taille de la rangée est trop grande (> 8126). Changer certaines colonnes en TEXTE ou BLOB ou utiliser ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED peut aider. Dans le format actuel des lignes, BLOB Le préfixe de 768 octets est stocké en ligne.

Table :

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

134voto

hjpotter92 Points 24797

La question a été posée sur défaut du serveur aussi.

Vous voudrez peut-être jeter un coup d'œil à cet article ce qui explique beaucoup de choses sur la taille des lignes MySQL. Il est important de noter que même si vous utilisez des champs TEXT ou BLOB, la taille de votre ligne peut toujours être supérieure à 8K (limite pour la technologie InnoDB), car les 768 premiers octets de chaque champ sont stockés dans la page la page.

La manière la plus simple de résoudre ce problème est d'utiliser la fonction Format du fichier Barracuda avec InnoDB. Cela permet de se débarrasser complètement du problème en en ne stockant que le pointeur de 20 octets vers les données texte au lieu de stocker les 768 premiers octets.


La méthode qui a fonctionné pour le PO était la suivante :

  1. Ajoutez les éléments suivants à la my.cnf fichier sous [mysqld] section.

    innodb_file_per_table=1
    innodb_file_format = Barracuda
  2. ALTER la table à utiliser ROW_FORMAT=COMPRESSED .

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

Il est possible que ce qui précède ne résolve toujours pas vos problèmes. Il s'agit d'un bogue connu (et vérifié) avec le InnoDB et une solution temporaire pour l'instant consiste à revenir à l'option MyISAM comme stockage temporaire. Ainsi, dans votre my.cnf fichier :

internal_tmp_disk_storage_engine=MyISAM

65voto

Colin Points 911

J'ai rencontré ce problème récemment et je l'ai résolu d'une manière différente. Si vous utilisez la version 5.6.20 de MySQL, il existe un bogue connu dans le système. Voir Documentation sur MySQL

Important En raison du bogue 69477, les écritures dans le redo log pour les champs BLOB volumineux stockés en externe pouvaient écraser le point de contrôle le plus récent. point de contrôle le plus récent. Pour résoudre ce bogue, un correctif introduit dans MySQL 5.6.20 limite la taille des écritures redo log BLOB à 10 % de la taille du fichier redo log. En raison de cette limite, innodb_log_file_size doit être définie à une valeur supérieure à 10 fois la plus grande taille des données BLOB trouvées dans les lignes de vos tables, plus la longueur des autres données de longueur variable. plus la longueur des autres champs de longueur variable (champs de type VARCHAR, VARBINARY, et TEXT).

Dans mon cas, la table de blob incriminée faisait environ 16 Mo. J'ai donc résolu le problème en ajoutant une ligne au fichier my.cnf pour m'assurer que je disposais d'au moins 10 fois cette quantité, voire plus :

innodb_log_file_size = 256M

46voto

Karl Points 631

Définissez les éléments suivants dans votre fichier my.cnf et redémarrez le serveur mysql.

innodb_strict_mode=0

25voto

phoenix Points 722

Si vous pouvez changer l'ENGINE et utiliser MyISAM au lieu d'InnoDB, cela devrait aider :

ENGINE=MyISAM

Il y a deux mises en garde avec MyISAM (peut-être plus) :

  1. Vous ne pouvez pas utiliser les transactions.
  2. Vous ne pouvez pas utiliser de contraintes de clé étrangère.

18voto

Eddy XP Points 1501

J'avais le même problème, ceci l'a résolu pour moi :

ALTER TABLE `my_table` ROW_FORMAT=DYNAMIC;

Depuis MYSQL Documentation :

Le format de rangée DYNAMIC maintient l'efficacité du stockage de la rangée entière dans le nœud d'index. dans le nœud d'index si cela convient (comme le font les formats COMPACT et REDONDANT). ), mais ce nouveau format évite le problème du remplissage des nœuds de l'arbre B avec un grand nombre d'octets de données de longues colonnes. Le format DYNAMIC repose sur l'idée que si une partie d'une longue valeur de données est stockée en dehors de la page, il est généralement plus facile de l'utiliser. est stockée hors page, il est généralement plus efficace de stocker toute la valeur hors page. valeur hors page. Avec le format DYNAMIC, les colonnes les plus courtes sont susceptibles de rester dans le nœud de l'arbre B, ce qui réduit le nombre de pages de débordement nécessaires pour une ligne donnée. nécessaires pour une ligne donnée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X