16.17 Restrictions sur les tables InnoDB

• Une table ne peut pas contenir plus de 1000 colonnes.
• La taille maximale d'une clé est de 1024 octets.
• La taille maximale d'une ligne, hormis pour les colonnes de type BLOB et TEXT , et légèrement inférieure à la moitié d'une page de base, c'est à dire, que la taille maximale d'une ligne est d'environs 8000 octets. Les colonnes LONGBLOB et LONGTEXT doivent être un peut plus petite que 4Go, et la taille totale d'une ligne, incluant les colonnes BLOB et TEXT doivent être de 4 Go. InnoDB stocke les 512 premiers octets des valeurs BLOB et TEXT dans la ligne, et le reste dans une page séparée.
• Sur certains systèmes d'exploitation, le fichier de données est limité à 2 Go.
• La taille combinée des fichiers de log doit être inférieure à 4 Go.
• La taille minimale d'un espace de tables est de 10Mo. La taille maximale d'un espace de tables est de 4 milliards de pages de bases (64To). C'est aussi la taille maximal d'une table.
• Les tables InnoDB ne supportent pas les index FULLTEXT .
• Sous Windows, InnoDB stocke les noms de bases de données et les noms de tables en interne, et en minuscule. Pour passer une base au format binaire de Unix à Windows, ou le contraire, vous devez créer toutes vos bases et tables en minuscules.
• Attention : NE convertissez PAS les tables de droits du format MyISAM en InnoDB ! Cela n'est pas supporté. Si vous faîtes cela, MySQL ne va pas redémarrer jusqu'à ce que vous restauriez vos données avec une vieille sauvegarde, ou que vous regénériez ces tables avec le script mysql_install_db .
• InnoDB ne conserve pas de compte interne de ligne pour une table. Cela serait en fait compliqué, à cause du multi-versionnage. Pour traiter une commande SELECT COUNT(*) FROM T , InnoDB doit scanner l'index de la table, ce qui prendra du temps si la table n'est pas enregistrée dans le buffer. Pour accélérer le compte, vous devez créer un compteur de table vous-même, et votre application le modifiera à chaque ajout ou suppression. Si votre table ne change pas souvent, l'utilisation du cache sera une bonne solution. SHOW TABLE STATUS peut aussi être utilisé pour obtenir un décompte approximatif des lignes. Paramétrage optimale d' InnoDB .
• Pour une colonne AUTO_INCREMENT , vous devez toujours définir un index pour la table, et cet index doit contenir uniquement la colonne AUTO_INCREMENT . Dans les tables MyISAM , la colonne AUTO_INCREMENT peut faire partie d'un index multi-colonne.
• InnoDB ne supporte pas l'option de configuration initale des colonnes AUTO_INCREMENT dans les commandes CREATE TABLE ou ALTER TABLE . Pour configurer cette valeur avec une table InnoDB , insérez une ligne avec une valeur inférieure d'une unité à votre valeur de départ, ou bien insérez la première ligne en spécifiant la première valeur.
• Lorque vous redémarrez le serveur MySQL, InnoDB peut réutiliser une ancienne valeur de la séquence AUTO_INCREMENT (c'est à dire, une valeur qui a été assignée à une transaction annulée).
• Lorsque la colonne AUTO_INCREMENT n'a plus de valeurs, InnoDB passe le BIGINT à -9223372036854775808 et les BIGINT UNSIGNED à 1 . Cependant, les valeurs BIGINT sont codées sur 64 bits, alors même si vous insérez 1 million lignes par seconde, cela vous prendra un million d'années avant d'atteindre la limite des BIGINT . Avec les autres types de colonnes, une erreur de clé doublon sera émise. C'est identique au fonctionnement des tables MyISAM , le comportement générale de MySQL, et ce n'est pas caractéristique d'un moteur spécifique.
• DELETE FROM TABLE ne regénère pas la table, mais au lieu de cela, il efface les lignes une à une, ce qui est bien plus lent. Dans les prochaines versions, MySQL va pouvoir utiliser la commande TRUNCATE qui est très rapide.
• TRUNCATE tbl_name est synonyme de DELETE FROM tbl_name pour InnoDB et ne remet pas à zéro le compteur de AUTO_INCREMENT .
• SHOW TABLE STATUS ne donne pas de statistiques exactes pour les tables InnoDB , hormis pour la taille physique réservée par la table. Le nombre de lignes n'est qu'une estimation utilisée pour les optimisations SQL.
• Si vous essayez de créer un index unique sur un préfixe d'une colonne, vous allez obtenir une erreur :

  CREATE TABLE T (A CHAR(20), B INT, UNIQUE (A(5))) TYPE = InnoDB;

  Si vous créez un index non-unique sur un préfixe de colonne, InnoDB va créer un index pour toute la colonne.

  Ces restrictions sont levées depuis les versions 4.0.14 et 4.1.1.

• INSERT DELAYED n'est pas supportés par les tables InnoDB .
• La commande MySQL LOCK TABLES ne reconnait pas le verrouillage de ligne InnoDB réalisé dans les commandes SQL achevées : cela signifie que vous pouvez poser un verrou sur une table même si il existe une transaction qui a été posée par un autre utilisateur. Par conséquent, votre opération doit attendre que les autres tables soient libres, et elle peut aussi entrer en conflit avec une autre requête. De plus, un blocage de verrous est possible mais il ne met pas en danger l'intégrité des transactions, car le verrou de ligne posé par InnoDB se charge toujours de l'intégrité. Enfin, un verrou de table évite aux autre transactions de poser un verrou de ligne (en conflit avec le mode de verrous) sur la table.
• Avant MySQL 3.23.52, la réplication fonctionnait toujours en mode d'auto-validation. Par conséquent, les lectures cohérentes de l'esclaves voyait aussi les transactions partiellement traitées, et la cohérence n'était pas assurée. Cette restriction a été levée en MySQL 3.23.52.
• La commande LOAD TABLE FROM MASTER de configuration de la réplication ne fonctionne pas pour les tables InnoDB . Un palliatif consiste à modifier la table en MyISAM sur le maître, faire la configuration, puis repasser la table en format InnoDB .
• La taille par défaut d'une page de base avec InnoDB est de 16Ko. En recompilant le code, vous pouvez donner une valeur allant de 8Ko à 64Ko. Vous mettre à jour les valeurs des constantes UNIV_PAGE_SIZE et UNIV_PAGE_SIZE_SHIFT dans le fichier univ.i .