MySQL: Code d'erreur: 1118 Taille de ligne trop grande (> 8126). Modification de certaines colonnes en TEXT ou BLOB
Je veux créer une table de 325 colonne:
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 les textes et j'ai ajouté Barracuda dans le fichier my.ini de MySQL, ce sont les attributs 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 base de données car c'est une application/système/base de données héritée. La création d'une nouvelle table est une exportation de la base de données existante.
EDIT2: j’ai écrit cette question qui ressemble à d’autres mais à l’intérieur il ya une solution que j’ai trouvée sur Internet comme VARCHAR et Barracuda, mais j’ai toujours ce problème, j’ai donc décidé d’ouvrir une nouvelle question avec déjà la réponse classique à quelqu'un a d'autres réponses
J'ai récemment eu du mal à utiliser le même code d'erreur en raison d'une modification de MySQL Server 5.6.20 . J'ai pu résoudre le problème en modifiant innodb_log_file_size dans le fichier texte my.ini.
Dans les notes de publication, il est expliqué qu'une taille de fichier innodb_log_file_size trop petite déclenchera une erreur "Erreur de taille de ligne trop importante".
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
J'ai essayé toutes les solutions ici, mais seulement ce paramètre
innodb_strict_mode = 0
résolu ma journée ...
Du manuel:
Le paramètre innodb_strict_mode affecte le traitement des erreurs de syntaxe pour les instructions CREATE TABLE, ALTER TABLE et CREATE INDEX . innodb_strict_mode active également une vérification de la taille d'enregistrement, de sorte qu'un INSERT. ou UPDATE n'échoue jamais car l'enregistrement est trop volumineux pour le taille de la 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_strict_mode = 0
ubuntu 16.04 modifier le chemin:
Sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
sur MS Windows, le chemin sera quelque chose comme:
C:\ProgramData\MySQL\MySQL Server 5.7\my.ini
N'oubliez pas de redémarrer le service (ou de redémarrer votre ordinateur)
J'ai récemment créé une table avec 82 colonnes et la même erreur avec InnoDB . Pour contourner le problème, nous avons basculé le format de table sur MyISAM car il était utilisé pour un formulaire de base.
Je veux juste aider d'autres personnes avec une variante plus sérieuse de ce problème. Dans certaines situations, l'erreur ("Taille de ligne trop grande .. Modification de certaines colonnes en TEXT ou BLOB") se produira même avec les instructions "alter table drop column" et "alter table modify column"!
Par conséquent, vous pouvez devenir complètement bloqué, incapable de changer un varchar en texte ou de supprimer des colonnes (essayer de résoudre le problème de façon ironique aboutit au même message).
Si vous rencontrez 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, colonne a, colonne b, colonne c" et si vous supprimez suffisamment de colonnes à la fois, il s’exécutera plutôt que de générer l’erreur.
MySQL est assez clair sur sa taille de ligne maximale:
Chaque table (quel que soit le moteur de stockage) a une taille de ligne maximale de 65 535 octets. Les moteurs de stockage peuvent imposer des contraintes supplémentaires à ce sujet limite, réduisant la taille maximale effective de la ligne.
. . .
Les moteurs de stockage individuels peuvent imposer des restrictions supplémentaires qui nombre limite de colonnes de la table. Exemples:
InnoDB autorise jusqu'à 1000 colonnes.
InnoDB limite la taille des lignes à moins de la moitié d'une page de base de données (environ 8 000 octets), n’incluant pas VARBINARY, VARCHAR, BLOB ou TEXT colonnes.
Les différents formats de stockage InnoDB (COMPRESSED, REDUNDANT) utilisent différents quantités d'en-tête de page et de données de fin, ce qui affecte la quantité de stockage disponible pour les lignes.
Si vous avez 325 ensembles répétés de colonnes, vous dépassez plusieurs des restrictions. C'est aussi 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.
(REAL SOLUTION MYSQL 5.7)
J'ai rencontré la même erreur sur le dernier serveur mysql (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, trouvé la solution!
Le paramètre clé est: innodb_page_size
La prise en charge des formats de page 32 000 et 64 000 a été ajoutée dans MySQL 5.7. Pour les tailles de page 32 ko et 64 ko, la longueur maximale de la ligne est d'environ 16 000 octets.
Le truc, c’est que ce paramètre ne peut être modifié que pendant l’INITIALISATION de l’instance de service mysql, donc n’a aucun effet si vous modifiez ce paramètre après que l’instance est déjà initialisée (la toute première exécution de l'instance).
innodb_page_size ne peut être configuré qu'avant l'initialisation de l'instance MySQL et ne peut pas ê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».
Par conséquent, si vous ne modifiez pas cette valeur dans my.ini avant l'initialisation, la valeur par défaut sera 16 Ko, ce qui limitera la taille des lignes à environ 8 Ko. C'est pourquoi l'erreur se produit.
Si vous augmentez innodb_page_size, vous devez également augmenter innodb_log_buffer_size. Réglez au moins 16M. De même, si ROW_FORMAT est défini sur COMPRESSÉ, vous ne pouvez pas augmenter innodb_page_size à 32k ou 64K. Ce devrait être DYNAMIC (défaut dans 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) lors de l’utilisation de formats de page de 32 ko ou de 64 ko.
De plus, innodb_buffer_pool_size devrait être augmenté de 128M à 512M 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, c'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 qui fonctionnent (après avoir créé une nouvelle instance et initialisé avec le fichier my.ini modifié en premier avec ces paramètres):
innodb_page_size=64k
innodb_log_buffer_size=32M
innodb_buffer_pool_size=512M
Tous les paramètres 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!
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 ajouter 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'existerait pas.
cmd : Sudo mkdir /usr/local/mysql/etc
Une fois que my.cnf est créé sous etc., il est temps de définir une variable à l'intérieur de celle-ci.
cmd: Sudo nano my.cnf
définir les variables ci-dessous [mysqld]
[mysqld]
innodb_log_file_size = 512M
innodb_strict_mode = 0
maintenant démarrez un serveur!
Passer à MyISAM n'est pas la solution. Pour innodb, la suite a fonctionné pour moi.
définir les suivants sur my.cnf
innodb_strict_mode = 0
Quel mien fixe était d'ajouter
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
J'ai aussi rencontré ça. Changer "innodb_log_file_size", "innodb_log_buffer_size" et les autres paramètres du fichier "my.ini" n'a pas résolu mon problème. Je le passe en changeant le type de colonne "texte" en varchar (20) et en n'utilisant pas de valeurs varchar supérieures à 20. Peut-être pourriez-vous aussi réduire la taille des colonnes, si cela est possible .. Texte ---> varchar (20) Varchar (256) -> varchar (20)
Le même problème ce matin et la manière suivante m'ont sauvé la vie:
Est-ce que vous essayez de désactiver le innodb_strict_mode?
SET GLOBAL innodb_strict_mode = 0;
puis essayez à nouveau d'importer.
innodb_strict_mode est activé avec MySQL> = 5.7.7, avant était désactivé.
si vous utilisez MySQLWorkbench, vous avez la possibilité de modifier le paramètre query_alloc_block_size = 16258 et de l'enregistrer.
Étape 1. Cliquez sur le options file à gauche . 
Étape 2: cliquez sur General et sélectionnez la checkBox de query_alloc_block_size et augmentez leur taille. par exemple, changement 8129 -> 16258
Aucune des réponses à ce jour ne mentionne l'effet du paramètre innodb_page_size. Peut-être parce que changer ce paramètre n'était pas une opération supportée 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 base de données pour des tailles de page de 4 Ko, 8 Ko, 16 Ko et 32 Ko. Par exemple, la longueur de ligne maximale pour la taille 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 faire moins de 4 Go et la longueur totale de la ligne, 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 une fois de la documentation:
Depuis MySQL 5.7.6, les formats de page de 32 Ko et 64 Ko sont pris en charge, mais ROW_FORMAT = COMPRESSED n'est toujours pas pris en charge pour les formats de page supérieurs à 16 Ko. Pour les formats de page de 32 Ko et 64 Ko, la taille d'enregistrement maximale 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 de fichiers de données ou de journaux d'une instance utilisant une taille de page différente. Cette limitation peut affecter les opérations de restauration ou de rétrogradation en utilisant les données de MySQL 5.6, qui prend en charge des tailles de page autres que 16 Ko.
Si vous obtenez cette erreur sur Google Cloud SQL (mysql 5.7 par exemple), il ne s'agit probablement pas pour l'instant d'une solution simple, car tous les indicateurs InnoDB ne sont pas pris en charge. Si vous tombez sur Mysql 5.5 tel que je l'étais (pour une ancienne configuration Wordpress), cela peut signifier que vous devez détruire certains types de colonnes dans la base de données source avant de les exporter.
Quelques informations supplémentaires peuvent être trouvées ici .
Dans mon cas, il s'agissait de Limits on Table Count Table and Row Size Et les modifications décrites dans cette réponse ont permis de sauver la journée.
Ajoutez ce qui suit au fichier my.cnf dans la section [mysqld].
innodb_file_per_table
innodb_file_format = BarracudaALTER la table pour utiliser ROW_FORMAT = COMPRESSED.
ALTER TABLE nom_table
MOTEUR = InnoDB
ROW_FORMAT = COMPRESSED
KEY_BLOCK_SIZE = 8;