Selon les documents en ligne , il y a une limite de 64 Ko et vous pouvez déterminer la taille de la ligne en utilisant:
row length = 1
+ (sum of column lengths)
+ (number of NULL columns + delete_flag + 7)/8
+ (number of variable-length columns)
Vous devez garder à l'esprit que les longueurs de colonne ne sont pas un mappage un à un de leur taille. Par exemple, CHAR(10) CHARACTER SET utf8
nécessite trois octets pour chacun des dix caractères, car cet encodage particulier doit prendre en compte la propriété de trois octets par caractère de utf8
(c'est l' utf8
encodage de MySQL plutôt que le "vrai" UTF-8, qui peut avoir jusqu'à quatre octets ).
Mais, si la taille de votre ligne approche 64 Ko, vous souhaiterez peut-être examiner le schéma de votre base de données. C'est une table rare qui doit être aussi large dans une base de données correctement configurée (3NF) - c'est possible, mais pas très courant.
Si vous souhaitez utiliser plus que cela, vous pouvez utiliser les types BLOB
ou TEXT
. Ceux-ci ne comptent pas dans la limite de 64 Ko de la ligne (autre qu'une petite empreinte administrative), mais vous devez être conscient des autres problèmes qui découlent de leur utilisation, tels que le fait de ne pas pouvoir trier en utilisant tout le bloc de texte au-delà d'un certain nombre. de caractères (bien que cela puisse être configuré vers le haut), forçant les tables temporaires à être sur le disque plutôt que dans la mémoire, ou à configurer des tampons de communication client et serveur pour gérer efficacement les tailles.
Les tailles autorisées sont:
TINYTEXT 255 (+1 byte overhead)
TEXT 64K - 1 (+2 bytes overhead)
MEDIUMTEXT 16M - 1 (+3 bytes overhead)
LONGTEXT 4G - 1 (+4 bytes overhead)
Vous avez toujours l'inadéquation octet / caractère (de sorte qu'une MEDIUMTEXT utf8
colonne peut stocker "seulement" environ un demi-million de caractères (16M-1)/3 = 5,592,405
), mais elle étend encore considérablement votre plage.