MySQL: Code d’erreur: 1118 Taille de la ligne trop grande (> 8126). Modification de certaines colonnes en TEXT ou BLOB

Je veux créer une table de 325 colonnes:

CREATE TABLE NAMESCHEMA.NAMETABLE ( ROW_ID TEXT NOT NULL , //this is the primary key 324 column of these types: CHAR(1), DATE, DECIMAL(10,0), DECIMAL(10,7), TEXT, LONG, ) ROW_FORMAT=COMPRESSED; 

J’ai remplacé tous les VARCHAR par le TEXT et j’ai ajouté Barracuda dans le fichier my.ini de MySQL, voici les atsortingbuts ajoutés:

 innodb_file_per_table=1 innodb_file_format=Barracuda innodb_file_format_check = ON 

mais j’ai toujours cette erreur:

 Error Code: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline. 

EDIT: Je ne peux pas changer la structure de la firebase database car c’est une application / un système / une firebase database hérité. La création d’une nouvelle table, c’est une exportation de la firebase database existante.

EDIT2: j’ai écrit cette question qui est similaire aux autres mais à l’intérieur il y a une solution que j’ai trouvée sur internet comme VARCHAR et Barracuda, mais j’ai toujours ce problème donc j’ai décidé d’ouvrir une nouvelle question avec la réponse classique quelqu’un a d’autres réponses

J’ai eu du mal avec le même code d’erreur récemment, en raison d’une modification de MySQL Server 5.6.20. J’ai pu résoudre le problème en changeant le fichier innodb_log_file_size dans le fichier texte my.ini.

Dans les notes de version, il est expliqué qu’un innodb_log_file_size trop petit déclenche une “erreur de taille de ligne trop importante”.

http://dev.mysql.com/doc/relnotes/mysql/5.6/fr/news-5-6-20.html

J’ai essayé toutes les solutions ici, mais seulement ce paramètre

 innodb_ssortingct_mode = 0 

résolu ma journée …

A partir du manuel:

Le paramètre innodb_ssortingct_mode affecte le traitement des erreurs de syntaxe pour les instructions CREATE TABLE, ALTER TABLE et CREATE INDEX. innodb_ssortingct_mode active également une vérification de la taille de l’enregistrement, de sorte qu’un INSERT ou UPDATE n’échoue jamais car l’enregistrement est trop grand pour la taille de page sélectionnée.

 ERROR 1118 (42000) at line 1852: Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline. 

 [mysqld] innodb_log_file_size = 512M innodb_ssortingct_mode = 0 

ubuntu 16.04 edit path:

 sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf 

sur MS Windows, le chemin sera comme suit:

 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini 

N’oubliez pas de redémarrer le service (ou de redémarrer votre machine)

J’ai récemment créé une table avec 82 colonnes et j’ai eu la même erreur avec InnoDB. Pour contourner le problème, nous avons basculé le format de la table vers MyISAM car il était juste utilisé pour un formulaire de base.

MySQL est assez clair sur sa taille de ligne maximale:

Chaque table (indépendamment du moteur de stockage) a une taille de ligne maximale de 65 535 octets. Les moteurs de stockage peuvent imposer des contraintes supplémentaires à cette limite, réduisant ainsi la taille de ligne maximale effective.

. . .

Les moteurs de stockage individuels peuvent imposer des ressortingctions supplémentaires qui limitent le nombre de colonnes de la table. Exemples:

InnoDB permet jusqu’à 1000 colonnes.

InnoDB limite la taille des lignes à moins de la moitié d’une page de firebase database (environ 8 000 octets), à l’exclusion des colonnes VARBINARY, VARCHAR, BLOB ou TEXT.

Différents formats de stockage InnoDB (COMPRESSED, REDUNDANT) utilisent différentes quantités de données d’en-tête et de remorque, ce qui affecte la quantité de stockage disponible pour les lignes.

Si vous disposez de 325 ensembles de colonnes répétés, vous dépassez plusieurs des ressortingctions. C’est également un format de données suspect. Vous devez avoir 325 lignes pour chaque ligne de la table souhaitée, une pour chaque groupe de colonnes.

Je veux juste aider d’autres personnes avec une variante plus sérieuse de ce problème. Dans certaines situations, l’erreur (“Taille de la ligne trop grande .. Modification de certaines colonnes en TEXTE ou BLOB”) se produit même avec les instructions “Modifier la colonne de suppression de table” et “Modifier la colonne de modification de table”!

Par conséquent, vous pouvez être complètement bloqué, ne pas pouvoir modifier un varchar en texte, ou supprimer des colonnes (essayer de résoudre le problème revient ironiquement au même message).

Si vous avez ce problème, la solution consiste à modifier ou supprimer plusieurs colonnes à la fois. Vous pouvez le faire dans MySQL avec la syntaxe “alter table example drop colonne a, drop colonne b, drop colonne c” et si vous déposez suffisamment de colonnes à la fois, il va réellement s’exécuter plutôt que de générer l’erreur.

Pour MySQL 5.7 sur Mac OS X El Capitan:

OS X fournit des exemples de fichiers de configuration dans /usr/local/mysql/support-files/my-default.cnf

Pour append des variables, arrêtez d’abord le serveur et copiez simplement le fichier ci-dessus dans /usr/local/mysql/etc/my.cnf

 cmd : sudo cp /usr/local/mysql/support-files/my-default.cnf /usr/local/mysql/etc/my.cnf 

NOTE: créez le dossier ‘etc’ sous ‘mysql’ au cas où il n’existe pas.

 cmd : sudo mkdir /usr/local/mysql/etc 

Une fois le fichier my.cnf créé, etc., il est temps de définir une variable à l’intérieur de celui-ci.

 cmd: sudo nano my.cnf 

définir les variables ci-dessous [mysqld]

 [mysqld] innodb_log_file_size = 512M innodb_ssortingct_mode = 0 

maintenant, lancez un serveur!

Passer à MyISAM n’est pas la solution. Pour innodb suivant a travaillé pour moi.

définir les suivis sur my.cnf

innodb_ssortingct_mode = 0

J’ai aussi rencontré ça. Changer “innodb_log_file_size”, “innodb_log_buffer_size” et les autres parameters du fichier “my.ini” n’a pas résolu mon problème. Je le passe en changeant mes types de colonnes “text” en varchar (20) et en n’utilisant pas les valeurs de varchar supérieures à 20. Peut-être pouvez-vous également réduire la taille des colonnes, si possible. text —> varchar (20) varchar (256) -> varchar (20)

Quelle mine fixe était d’append

 SET GLOBAL innodb_file_format=Barracuda; SET GLOBAL innodb_file_per_table=ON; 

Au début de mon fichier “.sql”, comme il est dit dans: https://gist.github.com/tonykwon/8910261

Avoir le même problème ce matin et de la manière suivante m’a sauvé la vie:

Essayez-vous de désactiver le mode innodb_ssortingct_mode ?

 SET GLOBAL innodb_ssortingct_mode = 0; 

puis essayez à nouveau d’importer.

innodb_ssortingct_mode est activé en utilisant MySQL> = 5.7.7, avant était OFF.

Aucune des réponses à ce jour ne mentionne l’effet du paramètre innodb_page_size. Peut-être parce que la modification de ce paramètre n’était pas une opération prise en charge avant MySQL 5.7.6. De la documentation :

La longueur maximale des lignes, à l’exception des colonnes de longueur variable (VARBINARY, VARCHAR, BLOB et TEXT), est légèrement inférieure à la moitié d’une page de firebase database pour des tailles de page de 4 Ko, 8 Ko, 16 Ko et 32 ​​Ko. Par exemple, la longueur maximale de ligne pour la valeur par défaut innodb_page_size de 16 Ko est d’environ 8 000 octets. Pour une taille de page InnoDB de 64 Ko, la longueur de ligne maximale est d’environ 16 000 octets. Les colonnes LONGBLOB et LONGTEXT doivent être inférieures à 4 Go et la longueur totale des lignes, y compris les colonnes BLOB et TEXT, doit être inférieure à 4 Go.

Notez que l’augmentation de la taille de la page n’est pas sans inconvénients. Encore de la documentation:

A partir de MySQL 5.7.6, les tailles de page de 32 Ko et 64 Ko sont sockets en charge, mais ROW_FORMAT = COMPRESSED n’est toujours pas pris en charge pour les tailles de page supérieures à 16 Ko. Pour les tailles de page de 32 Ko et de 64 Ko, la taille maximale d’enregistrement est de 16 Ko. Pour innodb_page_size = 32k, la taille de l’extension est de 2 Mo. Pour innodb_page_size = 64k, la taille de l’extension est de 4 Mo.

Une instance MySQL utilisant une taille de page InnoDB particulière ne peut pas utiliser les fichiers de données ou les fichiers journaux d’une instance utilisant une taille de page différente. Cette limitation pourrait affecter les opérations de restauration ou de rétrogradation utilisant des données de MySQL 5.6, qui prennent en charge des tailles de page autres que 16 Ko.

Si vous utilisez MySQLWorkbench, vous avez la possibilité de changer le paramètre pour modifier le paramètre query_alloc_block_size = 16258 et l’enregistrer.

Étape 1. Cliquez sur le options file à gauche. entrer la description de l'image ici

Etape 2: cliquez sur General et sélectionnez le checkBox de query_alloc_block_size et augmentez leur taille. par exemple changer 8129 -> 16258

entrer la description de l'image ici

Dans mon cas, il était extrait des limites sur le nombre de colonnes et la taille des lignes de la table et les modifications décrites dans cette réponse ont sauvé ma journée.

  1. Ajoutez ce qui suit au fichier my.cnf sous la section [mysqld].

    innodb_file_per_table
    innodb_file_format = Barracuda

  2. ALTER la table pour utiliser ROW_FORMAT = COMPRESSED.

    ALTER TABLE nom_table
    MOTEUR = InnoDB
    ROW_FORMAT = COMPRESSED
    KEY_BLOCK_SIZE = 8;

https://stackoverflow.com/a/15585700/2195130

(REAL SOLUTION MYSQL 5.7)

J’ai rencontré la même erreur sur le serveur mysql le plus récent (5.7.21):

Taille de la ligne trop grande (> 8126). Changer certaines colonnes en TEXT ou BLOB peut aider. Dans le format de ligne actuel, le préfixe BLOB de 0 octet est stocké en ligne.

Après avoir passé quelques heures à lire le manuel de MYSQL, j’ai trouvé la solution!

Le paramètre clé est: innodb_page_size

La prise en charge des tailles de page 32k et 64k a été ajoutée dans MySQL 5.7. Pour les tailles de page 32k et 64k, la longueur de ligne maximale est d’environ 16 000 octets.

L’astuce est que ce paramètre ne peut être modifié que pendant l’INITIALIZATION de l’instance du service mysql, il n’a donc aucun effet si vous modifiez ce paramètre après l’initialisation de l’instance (la toute première exécution de l’instance).

innodb_page_size peut uniquement être configuré avant l’initialisation de l’instance MySQL et ne peut plus être modifié par la suite. Si aucune valeur n’est spécifiée, l’instance est initialisée à l’aide de la taille de page par défaut. Voir Section 14.6.1, «Configuration de démarrage InnoDB».

Donc, si vous ne modifiez pas cette valeur dans my.ini avant l’initialisation, la valeur par défaut sera 16K, ce qui aura une taille de ligne limitée à ~ 8K. Thats pourquoi l’erreur se lève.

Si vous augmentez la taille innodb_page_size, la taille innodb_log_buffer_size doit également être augmentée. Réglez-le au moins à 16M. De plus, si ROW_FORMAT est défini sur COMPRESSED, vous ne pouvez pas augmenter innodb_page_size à 32k ou 64K. Cela devrait être DYNAMIQUE (par défaut en 5.7).

ROW_FORMAT = COMPRESSED n’est pas pris en charge lorsque innodb_page_size est défini sur 32 Ko ou 64 Ko. Pour innodb_page_size = 32k, la taille de l’extension est de 2 Mo. Pour innodb_page_size = 64k, la taille de l’extension est de 4 Mo. innodb_log_buffer_size doit être défini sur au moins 16 Mo (valeur par défaut) lorsque vous utilisez des tailles de page de 32 ou 64 Ko.

En outre, innodb_buffer_pool_size devrait être augmenté de 128 Mo à 512 Mo au moins, sinon vous obtiendrez une erreur lors de l’initialisation de l’instance (je n’ai pas l’erreur exacte).

Après cela, l’erreur de taille de ligne a disparu.

Le problème est que vous devez créer une nouvelle instance MySql et migrer les données vers votre nouvelle instance DataBase, à partir de l’ancienne.

Paramètres que j’ai modifiés et fonctionnent (après avoir créé une nouvelle instance et initialisé avec my.ini modifié en premier avec ces parameters):

 innodb_page_size=64k innodb_log_buffer_size=32M innodb_buffer_pool_size=512M 

Tous les parameters et descriptions dans lesquels j’ai trouvé la solution peuvent être trouvés ici:

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html

J’espère que cela t’aides!

Cordialement!