--- title: "Tipos TEXT en MySQL: TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT" excerpt: "El tamaño máximo de cada tipo de texto en MySQL —TINYTEXT, TEXT, MEDIUMTEXT y LONGTEXT— en bytes y en caracteres, sus diferencias, y cómo elegir el correcto sin tener que migrar la tabla después." date: "2019-09-21T20:01:45.000Z" lastModified: "2026-06-15" category: "Bases de Datos" tech_article: true seo_title: "TINYTEXT, TEXT, MEDIUMTEXT y LONGTEXT en MySQL: tamaños y usos" seo_description: "Tamaño máximo de los tipos TEXT de MySQL: TINYTEXT 255 B, TEXT 64 KiB, MEDIUMTEXT 16 MiB, LONGTEXT 4 GiB (4 294 967 295 bytes). Diferencias, bytes vs caracteres y cuándo usar cada uno." author: name: "angel cruz" picture: "https://angelcruzdevcdn.nyc3.cdn.digitaloceanspaces.com/images/me/angel-cruz.png" --- Cuando diseño una tabla siempre llega la misma pregunta: para un campo de texto largo, ¿qué tipo uso? MySQL ofrece cuatro tipos de cadena pensados para esto —`TINYTEXT`, `TEXT`, `MEDIUMTEXT` y `LONGTEXT`— y la única diferencia real entre ellos es **cuántos bytes pueden almacenar**. Elegir el correcto desde el principio te evita migrar la tabla a mitad del proyecto. Aquí va la respuesta directa y, después, todo lo que conviene saber para no equivocarte. ## Tamaño máximo de cada tipo | Tipo | Tamaño máximo (bytes) | Equivalente | Prefijo de longitud | | --- | --- | --- | --- | | `TINYTEXT` | 255 (2⁸−1) | 255 B | 1 byte | | `TEXT` | 65 535 (2¹⁶−1) | 64 KiB | 2 bytes | | `MEDIUMTEXT` | 16 777 215 (2²⁴−1) | 16 MiB | 3 bytes | | `LONGTEXT` | 4 294 967 295 (2³²−1) | 4 GiB | 4 bytes | Ese `4 294 967 295` es el famoso límite de `LONGTEXT`: cuatro gigabytes por valor. Cada tipo guarda, además del contenido, un **prefijo de longitud** de 1 a 4 bytes que indica el tamaño del dato. > El tamaño en **bytes** es fijo, pero la cantidad de **caracteres** que entran depende de la codificación que uses. No es lo mismo `latin1` (1 byte por carácter) que `utf8mb4` (hasta 4 bytes por carácter). ## TINYTEXT en MySQL Hasta **255 bytes**. Es el más chico de la familia y rara vez lo elijo: para cadenas cortas casi siempre me conviene más un `VARCHAR(n)`, que se indexa completo y puede tener valor por defecto. `TINYTEXT` tiene sentido si quiero comportamiento de tipo TEXT (almacenamiento fuera de fila, sin `DEFAULT` literal) en un campo muy pequeño. ## TEXT en MySQL Hasta **65 535 bytes (64 KiB)**. Es el caballo de batalla: comentarios, descripciones, biografías, mensajes. Cubre la inmensa mayoría de los casos de "texto largo" sin desperdiciar nada. Si no estás seguro de cuál usar y el contenido es texto humano normal, `TEXT` es la apuesta segura. ## MEDIUMTEXT en MySQL Hasta **16 777 215 bytes (16 MiB)**. Lo uso cuando el contenido puede crecer de verdad: artículos completos en HTML o Markdown, payloads JSON medianos, el cuerpo serializado de un documento. Es el escalón que casi nadie recuerda que existe y que muchas veces es justo lo que hace falta antes de saltar a `LONGTEXT`. ## LONGTEXT en MySQL Hasta **4 294 967 295 bytes (4 GiB)**. Para datos realmente grandes: documentos enormes, dumps, contenido en base64, logs acumulados. Funciona, pero antes de llegar a ese extremo vale la pena preguntarse si una base de datos relacional es el lugar correcto para ese dato; muchas veces conviene guardar el archivo en un object storage (S3, Spaces) y dejar en MySQL solo la referencia. ## Comparativas rápidas ### LONGTEXT vs TEXT Misma semántica, distinto techo: `TEXT` llega a 64 KiB y `LONGTEXT` a 4 GiB. La regla que sigo es **usar el tipo más chico que cubra mi caso real**. Un `LONGTEXT` "por las dudas" no es gratis: complica los índices y puede inflar el uso de memoria en operaciones que materializan la columna (por ejemplo, ciertos `GROUP BY` o tablas temporales). ### MEDIUMTEXT vs TEXT `TEXT` son 64 KiB; `MEDIUMTEXT`, 16 MiB. Si tu contenido puede superar los 64 KiB —un artículo largo, un JSON que crece— `TEXT` te va a truncar el dato en silencio (o lanzar error según el modo SQL). Ahí `MEDIUMTEXT` es el salto natural. ### TEXT vs VARCHAR Esta es la duda más común. La diferencia práctica: - **`VARCHAR(n)`**: pensado para cadenas con una longitud máxima conocida (hasta 65 535 bytes, compartidos con el resto de la fila). Se guarda en la fila, se indexa completo y admite `DEFAULT`. Ideal para nombres, emails, slugs, títulos. - **`TEXT`** y familia: para contenido grande o sin tope claro. Se almacena fuera de la fila (en InnoDB), **no** admite `DEFAULT` literal antes de MySQL 8.0.13 y solo se indexa por prefijo. Si conozco el límite y es razonable, voy con `VARCHAR`. Si el texto es grande o impredecible, voy con `TEXT`/`MEDIUMTEXT`. ## Bytes vs caracteres: el matiz que casi nadie explica El máximo en bytes no cambia, pero los **caracteres** que entran sí, según la codificación. Con `utf8mb4` (la que deberías estar usando), un carácter ocupa hasta 4 bytes, así que el máximo en caracteres es el límite en bytes dividido entre 4: | Tipo | Máx. en `latin1` (1 B/car.) | Máx. en `utf8mb4` (≤4 B/car.) | | --- | --- | --- | | `TINYTEXT` | 255 | 63 | | `TEXT` | 65 535 | 16 383 | | `MEDIUMTEXT` | 16 777 215 | 4 194 303 | | `LONGTEXT` | 4 294 967 295 | 1 073 741 823 | Por eso un campo que "entraba justo" en `latin1` puede quedarte corto al migrar a `utf8mb4`. Es un detalle que se paga caro si aparece en producción. ## Detalles que importan en producción - **Overhead del prefijo**: cada valor agrega 1, 2, 3 o 4 bytes según el tipo, además del contenido. - **Índices por prefijo**: no puedes indexar una columna `TEXT` completa; tienes que indicar una longitud, por ejemplo `INDEX (columna(255))`. El máximo del prefijo depende del motor y el formato de fila (en InnoDB, 767 bytes por defecto, hasta 3072 con formato `DYNAMIC`/`COMPRESSED`). - **Almacenamiento fuera de fila**: InnoDB guarda los valores grandes en páginas de overflow, no inline. La fila solo lleva un puntero, por eso puedes tener varias columnas `TEXT` sin chocar contra el límite de 65 535 bytes por fila. - **`DEFAULT`**: los tipos `TEXT` no aceptan un valor por defecto literal antes de MySQL 8.0.13. ## Cuándo usar cada uno - Cadena corta con tope conocido (nombre, email, slug) → **`VARCHAR(n)`**. - Texto humano normal hasta 64 KiB (comentarios, descripciones) → **`TEXT`**. - Contenido que puede crecer hasta 16 MiB (artículos, Markdown largo, JSON mediano) → **`MEDIUMTEXT`**. - Datos enormes hasta 4 GiB (documentos, base64, logs) → **`LONGTEXT`** (y considera un object storage externo). Con eso ya tienes con qué diseñar tus tablas sin tener que rehacerlas después. Y si trabajas seguido con MySQL, te puede servir también [la diferencia entre WHERE y HAVING](/post/cual-es-la-diferencia-entre-where-y-having-en-mysql), otra duda clásica a la hora de escribir queries. ## Preguntas frecuentes ### ¿Cuál es el tamaño máximo de LONGTEXT en MySQL? 4 GiB: exactamente 4 294 967 295 bytes (2³²−1) por valor. ### ¿Cuántos caracteres caben en un TEXT? Depende de la codificación. En bytes el tope es 65 535; con `utf8mb4` (hasta 4 bytes por carácter) eso equivale a unos 16 383 caracteres, y con `latin1`, a 65 535. ### ¿Uso LONGTEXT o TEXT? El más chico que cubra tu caso real. `TEXT` (64 KiB) alcanza para casi todo; pasa a `MEDIUMTEXT` o `LONGTEXT` solo si el contenido lo justifica. Sobredimensionar complica índices y memoria. ### ¿TEXT o VARCHAR? `VARCHAR` para cadenas cortas con longitud acotada (se indexa completo y admite `DEFAULT`); `TEXT` para contenido grande o sin tope claro. ## Lecturas recomendadas - [Documentación oficial de MySQL: tipos de cadena](https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html) - [TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT maximum storage sizes (Stack Overflow)](https://stackoverflow.com/questions/13932750/tinytext-text-mediumtext-and-longtext-maximum-storage-sizes) --- ## Sitemap Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md) Canónico HTML: [https://www.angelcruz.dev/post/tamanos-maximos-de-almacenamiento-de-text-tinytext-mediumlong-text](https://www.angelcruz.dev/post/tamanos-maximos-de-almacenamiento-de-text-tinytext-mediumlong-text)