La longitud máxima de un varchar está sujeta al tamaño máximo de fila en MySQL, que es de 64 KB (sin contar los BLOB):
VARCHAR(65535)
Sin embargo, tenga en cuenta que el límite es menor si utiliza un conjunto de caracteres de varios bytes:
VARCHAR(21844) CHARACTER SET utf8
Estos son algunos ejemplos:
El tamaño de fila máximo es 65535, pero un varchar también incluye uno o dos bytes para codificar la longitud de una cadena determinada. Entonces, en realidad no puede declarar un varchar del tamaño de fila máximo, incluso si es la única columna en la tabla.
mysql> CREATE TABLE foo ( v VARCHAR(65534) );
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
Pero si intentamos disminuir las longitudes, encontramos la mayor longitud que funciona:
mysql> CREATE TABLE foo ( v VARCHAR(65532) );
Query OK, 0 rows affected (0.01 sec)
Ahora, si tratamos de usar un conjunto de caracteres multibyte a nivel de tabla, encontramos que cuenta cada carácter como múltiples bytes. Las cadenas UTF8 no necesariamente use múltiples bytes por cadena, pero MySQL no puede asumir que restringirá todas sus futuras inserciones a caracteres de un solo byte.
mysql> CREATE TABLE foo ( v VARCHAR(65532) ) CHARSET=utf8;
ERROR 1074 (42000): Column length too big for column 'v' (max = 21845); use BLOB or TEXT instead
A pesar de lo que nos dijo el último error, a InnoDB todavía no le gusta una longitud de 21845.
mysql> CREATE TABLE foo ( v VARCHAR(21845) ) CHARSET=utf8;
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
Esto tiene perfecto sentido, si calculas que 21845*3 =65535, lo cual no habría funcionado de todos modos. Mientras que 21844*3 =65532, que funciona.
mysql> CREATE TABLE foo ( v VARCHAR(21844) ) CHARSET=utf8;
Query OK, 0 rows affected (0.32 sec)
