Je voudrais savoir quelle est la taille maximale pour un type MySQL VARCHAR.
J'ai lu que la taille maximale est limitée par la taille de la ligne qui est d'environ 65k. J'ai essayé de définir le champ comme varchar(20000) mais cela indique que c'est trop grand.
Je pourrais le définir comme varchar(10000). Quelle est la taille maximale exacte que je peux définir?
Gardez à l'esprit que MySQL a une limite de taille maximale de ligne
La représentation interne d'une table MySQL a une limite de taille maximale de ligne de 65 535 octets, en ne comptant pas les types BLOB et TEXT. Les colonnes BLOB et TEXT ne contribuent que de 9 à 12 octets à la limite de taille de la ligne car leur contenu est stocké séparément du reste de la ligne. En savoir plus sur Limites sur le nombre de colonnes et la taille des lignes de table.
La taille maximale qu'une seule colonne peut occuper est différente avant et après MySQL 5.0.3
Les valeurs dans les colonnes VARCHAR sont des chaînes de longueur variable. La longueur peut être spécifiée comme une valeur de 0 à 255 avant MySQL 5.0.3, et de 0 à 65 535 dans les versions 5.0.3 et ultérieures. La longueur maximale effective d'un VARCHAR dans MySQL 5.0.3 et ultérieur est soumise à la taille maximale de la ligne (65 535 octets, partagée entre toutes les colonnes) et à l'ensemble de caractères utilisé.
Cependant, notez que la limite est plus basse si vous utilisez un jeu de caractères multioctets comme utf8 ou utf8mb4.
Utilisez les types TEXT pour contourner la limite de taille de ligne.
Les quatre types TEXT sont TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT. Ils correspondent aux quatre types BLOB et ont les mêmes longueurs maximales et exigences de stockage.
Plus de détails sur les types BLOB et TEXT
Encore plus
Consultez plus de détails sur Exigences de stockage des types de données qui traite des exigences de stockage pour tous les types de données.
J'essaie d'éviter les colonnes TEXT car elles peuvent entraîner la création de tables temporaires lorsqu'elles sont présentes et en cours de tri
Si je prends varchar(200) pour le prénom et que je ne stocke que 6 caractères dans ce champ, combien d'octets le prénom occupera-t-il?
According to the online docs, there is a 64K row limit and you can work out the row size by using:
row length = 1
+ (sum of column lengths)
+ (number of NULL columns + delete_flag + 7)/8
+ (number of variable-length columns)You need to keep in mind that the column lengths aren't a one-to-one mapping of their size. For example, CHAR(10) CHARACTER SET utf8 requires three bytes for each of the ten characters since that particular encoding has to account for the three-bytes-per-character property of utf8 (that's MySQL's utf8 encoding rather than "real" UTF-8, which can have up to four bytes).
But, if your row size is approaching 64K, you may want to examine the schema of your database. It's a rare table that needs to be that wide in a properly set up (3NF) database - it's possible, just not very common.
If you want to use more than that, you can use the BLOB or TEXT types. These do not count against the 64K limit of the row (other than a small administrative footprint) but you need to be aware of other problems that come from their use, such as not being able to sort using the entire text block beyond a certain number of characters (though this can be configured upwards), forcing temporary tables to be on disk rather than in memory, or having to configure client and server comms buffers to handle the sizes efficiently.
The sizes allowed are:
TINYTEXT 255 (+1 byte overhead)
TEXT 64K - 1 (+2 bytes overhead)
MEDIUMTEXT 16M - 1 (+3 bytes overhead)
LONGTEXT 4G - 1 (+4 bytes overhead)You still have the byte/character mismatch (so that a MEDIUMTEXT utf8 column can store "only" about half a million characters, (16M-1)/3 = 5,592,405) but it still greatly expands your range.
Gardez à l'esprit que les types TEXT ne peuvent PAS être stockés dans des tables en mémoire, donc il y a une pénalité de performance significative à les utiliser quand un VARCHAR suffirait.
"la propriété de trois octets par caractère de l'utf8" de MySql utf8, qui n'est en réalité pas du tout de l'utf8. En réalité, le nombre maximum d'octets dans un caractère utf-8 est 4. Pour cette raison, vous devriez toujours définir l'encodage sur utf8mb4 dans MySQL. utf8mb4 est le nom de MySQL pour ce que le reste du monde appelle utf8.
@StijndeWitt, merci pour cela. clarifié pour indiquer que je voulais dire la méthode d'encodage utf8 de MySQL plutôt que UTF-8. J'utilise généralement la variante en majuscules pour indiquer le "vrai" UTF-8 car c'est la convention acceptée par l'IANA.
Veuillez arrêter d'utiliser CHARACTER SET utf8 dans les exemples. Il devrait être CHARACTER SET utf8mb4 (si vous voulez que tout texte Unicode soit stocké correctement... et qui ne le voudrait pas ?)
En utilisant utf8mb4, vous atteindrez la limite de la largeur de l'index dans une situation où utf8 ne le fait pas. Si vous examinez les jeux de caractères inclus dans utf8mb4 mais pas dans utf8, vous pourriez constater que l'inclusion de toutes les formes de hiéroglyphes et autres jeux de caractères ésotériques ne vaut pas la peine de la pénalité de performance significative (déterminée empiriquement). Ce n'est pas aussi clair que ce que Stijn laisse entendre.
Vous pouvez également utiliser MEDIUMBLOB/LONGBLOB ou MEDIUMTEXT/LONGTEXT
Un type BLOB dans MySQL peut stocker jusqu'à 65 534 octets, si vous essayez de stocker plus de données que cela, MySQL tronquera les données. MEDIUMBLOB peut stocker jusqu'à 16 777 213 octets, et LONGBLOB peut stocker jusqu'à 4 294 967 292 octets.
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.
1 votes
Un blog détaillé: goo.gl/Hli6G3