Tipos de datos MySQL explicados: elige los tipos de columna correctos para rendimiento y escalabilidad

1. Introducción: Por qué deberías entender la lista de tipos de datos de MySQL

Cuando diseñas tablas o integras aplicaciones con MySQL, una de las preguntas más comunes es: “¿Qué tipo de dato debo usar para esta columna?”
¿Debería ser INT? ¿Realmente necesitas BIGINT? ¿Es VARCHAR suficiente para cadenas, o es mejor TEXT? Estas decisiones pueden parecer menores, pero forman la base que afecta a tu sistema más adelante.

Si subestimas cómo elegir los tipos de datos, a menudo te toparás con problemas como los siguientes:

• A medida que tus datos crecen más allá de lo esperado, desperdicias espacio de almacenamiento
• Los índices se inflan y el rendimiento de las consultas se degrada gradualmente
• Valores fuera de rango o desbordamientos provocan errores o excepciones inesperadas
• Te ves obligado a cambiar los tipos de columna más tarde, desencadenando una migración a gran escala

En otras palabras, comprender sistemáticamente los tipos de datos de MySQL y elegir el correcto para cada caso de uso es la forma más rápida de mejorar tanto el rendimiento como la mantenibilidad.

Esta página está dirigida principalmente a lectores como:

• Ingenieros que están a punto de iniciar un desarrollo serio de sistemas con MySQL
• Ingenieros de backend / infraestructura que quieren revisar diseños de tablas existentes
• Desarrolladores web y programadores que buscan “tipos recomendados” según el caso de uso

Comenzaremos organizando los principales tipos de datos de MySQL como una “lista” categorizada. Luego explicaremos los tipos clave—numéricos, de cadena, de fecha/hora, JSON, ENUM/SET—cubriendo sus características, casos de uso típicos y consejos de selección. Finalmente, resumiremos los errores de diseño más comunes y cómo evitarlos, junto con un FAQ.

Esto no es solo una “lista de términos”. Está estructurado como una guía de toma de decisiones para que no te quedes atascado al diseñar tablas en proyectos reales. En la siguiente sección, profundicemos en cómo pensar en los tipos de datos y revisemos la lista categorizada.

2. ¿Qué es un tipo de dato y por qué importa “elegir el tipo correcto”?

En una base de datos, un “tipo de dato” es una regla que define qué tipo de valores puede almacenar una columna.
MySQL ofrece muchos tipos de datos—enteros, decimales, cadenas, fechas, binarios, JSON y más—por lo que debes elegir adecuadamente según tu propósito.

El rol de los tipos de dato

Un tipo de dato no es solo una “categoría de formato”. Cumple varios roles al mismo tiempo:

• Restringir el tipo de datos (numérico vs. cadena, booleano, etc.)
• Definir el rango permitido y la cantidad de dígitos
• Determinar la memoria requerida (tamaño de almacenamiento)
• Influir en las estructuras de índices y el rendimiento de búsqueda
• Afectar conversiones implícitas y reglas de comparación (p. ej., colación de cadenas)

En resumen, los tipos de dato no son meramente “contenedores”; son decisiones de diseño fundamentales que impactan todo el ciclo de vida de la gestión de datos.

¿Qué ocurre si eliges el tipo equivocado?

Si seleccionas un tipo de dato incorrecto, con frecuencia aparecen problemas como los siguientes en el trabajo real:

• Desperdicio de almacenamiento

Por ejemplo, si BIGINT (8 bytes) es suficiente pero usas por error DECIMAL o LONGTEXT, puedes consumir mucho más espacio en disco del necesario.

• Consultas más lentas

Si abusas de búsquedas LIKE en columnas TEXT enormes, o si los índices se inflan porque elegiste tipos numéricos excesivamente grandes, la ejecución de SQL tiende a ralentizarse.

• Valores inconsistentes o desbordamiento

Puedes almacenar valores que no caben en INT, provocando valores negativos inesperados, redondeos u otros problemas.

• Cambios de tabla costosos

Especialmente en tablas grandes, cambiar tipos con ALTER TABLE puede generar:

• Largos tiempos de bloqueo
• Impacto en el servicio
• Trabajo de migración de datos y otros riesgos.

Categorías clave que debes entender desde el principio

Los tipos de datos de MySQL se agrupan ampliamente de la siguiente manera:

• Tipos numéricos (enteros, decimales)
• Tipos de cadena
• Tipos de fecha y hora
• Tipos binarios
• Tipo JSON
• Tipos ENUM / SET
• Tipos de datos espaciales

Cada categoría tiene diferentes compensaciones—fortalezas/debilidades, “ligero vs. pesado”, y “fácil vs. difícil de buscar”. Por eso necesitas la selección óptima de tipos para cada caso de uso.

3. Categorías de tipos de datos MySQL (Lista de visión general)

En esta sección, resumiremos los tipos de datos disponibles en MySQL como una lista de visión general categorizada. En la práctica, lo primero que deseas confirmar es “¿Qué tipos existen?” y “¿Cuál debería usar?”.
Así que aquí mostraremos claramente casos de uso, características clave y nombres representativos de tipos, y luego explicaremos cada categoría con más detalle en las secciones siguientes.

3.1 Tipos numéricos

Los tipos numéricos son la base de todo procesamiento numérico, incluidos enteros, decimales y valores de punto flotante.
Esta categoría se usa con mayor frecuencia para IDs, cantidades, precios, verificaciones de banderas y muchos otros propósitos.

Tipos enteros

Notas

• Añadir UNSIGNED duplica el rango positivo.
• INT se usa en muchos casos, pero usar BIGINT de forma casual puede hacer que los índices sean más pesados.

Tipos decimal / punto flotante

Notas

• Para dinero, DECIMAL es la única opción razonable. Los tipos de punto flotante (FLOAT / DOUBLE) pueden introducir errores.
• En casos que implican muchos cálculos, a veces se elige DOUBLE por compromisos de velocidad/precisión.

Otros tipos numéricos

3.2 Tipos de fecha y hora

El manejo de fechas/horas se usa con mucha frecuencia en el desarrollo de aplicaciones.
Dependiendo del propósito, factores como el “comportamiento de zona horaria”, las “actualizaciones automáticas” y la “precisión a nivel de segundo” varían, por lo que elegir el tipo correcto es importante.

Notas

• Si deseas gestionar “updated at” automáticamente, TIMESTAMP es conveniente.
• Para “logs” o “historial” donde deseas almacenar marcas de tiempo precisas, DATETIME se usa comúnmente.

3.3 Tipos de cadena / binario

Nombres de usuario, correos electrónicos, contraseñas, descripciones—las cadenas suelen ser el área más compleja en el diseño de tablas.

Cadenas de longitud fija

Cadenas de longitud variable

Texto grande (familia TEXT)

Notas

• Usa TEXT cuando necesites almacenar cadenas muy grandes, como cuerpos de artículos o descripciones largas.
• Ten cuidado con el diseño de búsquedas e índices.

Datos binarios (BINARY / BLOB)

※ En general, los archivos grandes no se almacenan en la base de datos; un diseño común es guardarlos en almacenamiento externo.

Tipos ENUM / SET (Enumeraciones)

Notas

• Si necesitas cambiar la definición del tipo más adelante, el mantenimiento se vuelve pesado
• Puede ser eficaz para candidatos estáticos y de pequeña escala

3.4 Tipo JSON

• Obtienes flexibilidad similar a NoSQL mientras aún puedes usar funciones específicas de JSON.
• Sin embargo, no se recomienda empaquetar datos buscados frecuentemente dentro de JSON. Si puede normalizarse, debería modelarse como tablas estructuradas.

3.5 Tipos espaciales

Se usan cuando se trabaja con datos geográficos y de ubicación.

En aplicaciones web típicas, no se usan con frecuencia, pero son importantes para aplicaciones de mapas e integraciones GPS.

4. Cómo elegir y usar cada tipo de dato (Puntos clave de decisión)

En esta sección, profundizamos en las categorías introducidas arriba, enfocándonos en “cómo elegir en escenarios del mundo real”.
Simplemente conocer los nombres no es suficiente—seleccionar el tipo de dato más adecuado tiene un gran impacto en el mantenimiento, el rendimiento y la escalabilidad futura.

4.1 Cómo elegir tipos numéricos

Criterios para elegir tipos enteros

Al seleccionar tipos enteros, concéntrate en estos tres puntos:

1. Entender el rango máximo requerido

• Contadores pequeños → TINYINT
• Cantidades de productos / banderas → SMALLINT / INT
• IDs o logs a gran escala → BIGINT

Algunos proyectos sobreutilizan BIGINT para claves primarias, pero esto puede generar índices más grandes y afectar negativamente el rendimiento.

2. Considerar activamente UNSIGNED

Si solo manejas valores positivos (p. ej., IDs numéricos, recuentos de inventario)
→ usar UNSIGNED duplica el rango y puede permitirte usar un tipo más pequeño.

3. Para valores monetarios o críticos en precisión, usa DECIMAL

Para valores donde “los errores no son aceptables”, evita FLOAT/DOUBLE y siempre usa DECIMAL.

4.2 Cómo elegir tipos de fecha y hora

El tipo apropiado depende de tu caso de uso.

Diferencias entre DATETIME y TIMESTAMP

Reglas generales para elegir

• Registros de aplicación o eventos → DATETIME (evita efectos de conversión de zona horaria)
• Cuando deseas registrar marcas de tiempo actualizadas automáticamente → TIMESTAMP (comportamiento conveniente de auto‑actualización)

Dónde es útil YEAR

• Categorías de año fiscal, años de lanzamiento, años de fundación, etc. → Gestionar de forma compacta (1 byte)

4.3 Cómo elegir tipos de cadena

Cómo decidir entre CHAR y VARCHAR

Cuándo deberías usar CHAR

• La longitud es siempre constante: códigos de prefectura, códigos de país, identificadores de longitud fija, etc.
• Datos que requieren acceso rápido y se actualizan con poca frecuencia

Cuándo deberías usar VARCHAR

• La longitud varía: nombres, direcciones de correo, títulos, etc.
• La mejor opción predeterminada en la mayoría de situaciones

¿Deberías usar TEXT?

Ventajas de TEXT

• Soporta texto grande (descripciones, cuerpos de artículos, etc.)

Precauciones con TEXT

• La indexación es limitada (se requieren índices de prefijo)
• El rendimiento puede degradarse al usarlo en JOINs o cláusulas WHERE
• La búsqueda y ordenación pueden ser costosas

Recomendación:
Usa TEXT para “cadenas grandes” como cuerpos o notas,
y usa VARCHAR tanto como sea posible para todo lo demás.

4.4 Cómo elegir el tipo JSON

El tipo JSON es muy útil, pero debes usarlo “correctamente”.

Cuando JSON funciona bien

• Configuraciones flexibles o datos con un número variable de campos
• Casos de uso de búsqueda limitada, o cuando la aplicación lo expande/analiza
• Almacenar datos ligeros que no requieren una tabla maestra

Cuando JSON no es adecuado

• Datos que buscas con frecuencia
• Datos usados para búsquedas filtradas, agregación o JOINs
• Datos estructurados que deberían normalizarse

Regla general:
Los datos que necesitas buscar deben estar normalizados y tratados como estructura.
No olvides que JSON es “flexible pero débil para la búsqueda”.

4.5 Cómo elegir tipos ENUM / SET

Cuando ENUM es apropiado

• Los estados son fijos: p. ej., estado (draft / published / archived)
• Un conjunto pequeño de opciones que rara vez cambia

Precauciones con ENUM

• Añadir o cambiar valores requiere ALTER TABLE
• Riesgo de perder consistencia con definiciones del lado de la aplicación

Cuando SET es apropiado

• Datos de pequeña escala que requieren selección múltiple (p. ej., días de la semana disponibles, o cuando solo hay unas pocas opciones de etiqueta)

Precauciones con SET

• Las combinaciones de valores pueden volverse complejas
• Gestionar estados multivalor puede resultar difícil

4.6 Cómo elegir tipos Binary / BLOB

BINARY / VARBINARY

• Tokens, IDs, valores hash, etc.
• Binario de longitud fija (p. ej., UUIDs de 16 bytes)

Casos de uso típicos para tipos BLOB

• Archivos pequeños, imágenes miniatura, datos encriptados

Pero nota

• Almacenar archivos grandes en la base de datos hace que las copias de seguridad sean más pesadas
• La carga de lectura/escritura también aumenta → En sistemas reales, se recomienda almacenamiento externo + gestión de rutas

5. Práctica: Cómo usar la “Lista de referencia de tipos de datos” al diseñar tablas

En esta sección, explicaremos cómo usar la lista de tipos de datos de MySQL en un flujo de trabajo práctico al diseñar tablas. En lugar de simplemente memorizar tipos, organizar “por qué eliges ese tipo” mediante lógica y pasos conduce a un diseño de base de datos de mayor calidad.

5.1 Paso 1: Aclarar el “Propósito” y la “Naturaleza” de la columna

Primero, define claramente qué se almacenará en la columna.

Lista de verificación

• ¿Es numérico, cadena, fecha o una bandera?
• ¿Tiene longitud variable o fija?
• ¿Cuál es el valor máximo o la longitud máxima?
• ¿Se debe permitir NULL?
• ¿Es probable que crezca en el futuro?

Si avanzas con suposiciones vagas aquí, la selección de tipos se vuelve innecesariamente complicada más adelante.

5.2 Paso 2: Estimar el Rango y Formato Requeridos

A continuación, estima los límites superior/inferior, la longitud de caracteres y la precisión requerida de los valores que almacenarás.

Ejemplo: Columna ID

• ¿El recuento máximo de registros alcanzará decenas de millones? ¿Cientos de millones? → Esto te ayuda a determinar si INT es suficiente o si es necesario BIGINT.

Ejemplo: Nombre del Producto

• ¿Promedio de 15–25 caracteres, máximo alrededor de 50? → VARCHAR(50) es suficiente. TEXT es innecesario.

Ejemplo: Precio

• ¿Se requiere precisión? → Deberías seleccionar algo como DECIMAL(10,2) .

5.3 Paso 3: Considerar el Volumen de Datos y el Rendimiento

Elegir tipos de datos en MySQL impacta directamente en el rendimiento.

Consideraciones Clave

• Tipos demasiado grandes → consumen almacenamiento y hacen que los índices sean más pesados
• TEXT / BLOB → degradan el rendimiento de búsqueda
• JSON → flexible pero débil para búsquedas
• TIMESTAMP → eficiente para actualizaciones automáticas y comparaciones

En particular, las columnas con índices deben usar el tipo de dato más ligero posible.

5.4 Paso 4: Validar los Tipos con Datos de Muestra

Después de diseñar la tabla, inserta decenas a cientos de filas de datos de prueba y verifica el comportamiento.

Qué Verificar

• ¿Hay problemas inesperados de redondeo o truncamiento?
• ¿VARCHAR es suficiente, o debería ser TEXT ?
• ¿El ordenamiento y la búsqueda de fechas/hora se comportan como se espera?
• Rendimiento de lectura/escritura de JSON

Probar con datos realistas reduce los “errores teóricos”.

5.5 Paso 5: Considerar la Escalabilidad y Mantenibilidad

En la etapa final del diseño de la tabla, verifica si los cambios futuros serán fáciles.

Ejemplos de Cambios de Tipo Significativos

• ENUM (requiere ALTER TABLE al agregar valores)
• TEXT → VARCHAR (expandir es fácil, reducir es arriesgado)
• FLOAT → DECIMAL (puede cambiar la semántica)

Elige los tipos juzgando si es probable una expansión futura.

5.6 Paso 6: Ejemplo de CREATE TABLE (Muestra Práctica)

A continuación se muestra una tabla de ejemplo que refleja los estándares comunes de selección de tipos de datos en una aplicación web típica.

CREATE TABLE products (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name         VARCHAR(100) NOT NULL,
    price        DECIMAL(10,2) NOT NULL,
    stock        INT UNSIGNED NOT NULL DEFAULT 0,
    status       ENUM('draft', 'published', 'archived') NOT NULL DEFAULT 'draft',
    description  TEXT,
    created_at   DATETIME NOT NULL,
    updated_at   TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

Puntos Clave en Este Ejemplo

• id : Usa BIGINT UNSIGNED considerando la escala futura
• name : Cadena variable de longitud media → VARCHAR
• price : Valor monetario → DECIMAL preciso
• stock : Conteo de inventario → INT UNSIGNED
• status : Conjunto fijo de valores → ENUM
• description : Texto potencialmente largo → TEXT
• updated_at : TIMESTAMP de actualización automática conveniente

Como se muestra, cada elección de tipo debe tener una razón clara, y poder articular esa justificación es una señal de buen diseño.

6. Errores Comunes y Cómo Evitarlos

Debido a que MySQL ofrece muchos tipos de datos, varios errores comunes aparecen frecuentemente en proyectos reales.
Esta sección destaca los escollos típicos y brinda contramedidas prácticas.

6.1 Usar Tipos de Datos Excesivamente Grandes

Ejemplos Comunes

• Usar BIGINT para todos los IDs
• Configurar todas las cadenas como VARCHAR(255)
• Usar TEXT para contenido no textual

Problemas

• Almacenamiento desperdiciado
• Índices inflados que perjudican el rendimiento de consultas
• Ancho de banda de red desperdiciado (transferencias de datos más grandes)

Cómo Evitar

• Estimar los valores máximos y mínimos de antemano
• Establecer longitudes de VARCHAR basadas en evidencia
• Usar TEXT solo cuando sea realmente necesario

6.2 Uso de FLOAT/DOUBLE para valores decimales (Problemas de precisión)

Ejemplos comunes

• Almacenar precios como FLOAT
• Las comparaciones numéricas fallan debido a errores de redondeo

Cómo evitar

• Use DECIMAL para dinero y valores críticos de precisión
• Evite FLOAT / DOUBLE excepto para cálculos científicos o temporales

6.3 Columnas VARCHAR sobredimensionadas

Ejemplos comunes

• Usar VARCHAR(255) como valor predeterminado
• Definir longitudes grandes para columnas que solo almacenan alrededor de 30 caracteres

Problemas

• Memoria y almacenamiento desperdiciados
• Los índices a menudo se vuelven más pesados

Cómo evitar

• Estime las longitudes promedio y máxima a partir de datos reales
• Evite tamaños innecesariamente grandes (p. ej., direcciones de correo electrónico → VARCHAR(100) )

6.4 Uso excesivo de tipos TEXT

Ejemplos comunes

• Asumir que “cadena = TEXT”
• Usar TEXT para datos que necesitan filtrado o búsqueda

Problemas

• Muchas limitaciones de indexación
• Búsquedas LIKE pesadas
• Procesamiento más lento en JOINs

Cómo evitar

• Use TEXT solo para contenido de formato largo, como descripciones o cuerpos
• Almacene cadenas buscables en VARCHAR siempre que sea posible

6.5 Elegir tipos de fecha/hora sin comprender sus propiedades

Ejemplos comunes

• Usar DATETIME para todo
• Usar DATETIME para “updated at”, de modo que no se actualice automáticamente
• Los TIMESTAMP cambian debido a diferencias de zona horaria

Cómo evitar

• Necesita auto‑actualización: TIMESTAMP
• Quiere evitar cambios de zona horaria: DATETIME
• Solo necesita el año: YEAR

6.6 Uso casual de ENUM / SET

Ejemplos comunes

• Usar ENUM aunque las opciones puedan cambiar en el futuro
• Usar SET como una lista separada por comas

Problemas

• Los cambios requieren ALTER TABLE
• Es más probable la inconsistencia con definiciones del lado de la aplicación

Cómo evitar

• Si los valores pueden incrementarse, adminístrelos en una tabla maestra separada
• Use ENUM solo cuando el conjunto sea pequeño y realmente fijo

6.7 Empaquetar demasiado en JSON “por conveniencia”

Ejemplos comunes

• Empaquetar estructuras que deberían estar normalizadas dentro de JSON
• Almacenar datos buscados frecuentemente dentro de JSON

Problemas

• El rendimiento de búsqueda se degrada
• Los índices son menos efectivos / más difíciles de usar
• Más trabajo de análisis en el lado de la aplicación
• El diseño sin esquema facilita romper la consistencia

Cómo evitar

• Use JSON solo para datos que no busca
• Limítelo a “datos pequeños y variables” como configuraciones
• Normalice la información usada para JOINs y búsquedas

6.8 Subestimar el costo de los cambios de tipo

Problemas

• ALTER TABLE puede ser extremadamente pesado en tablas grandes
• Puede producirse tiempo de inactividad del servicio o bloqueos prolongados
• En algunos casos, se requiere migración de datos

Cómo evitar

• Planifique el crecimiento futuro durante la fase de diseño
• Use ENUM con cuidado
• Deje espacio en la precisión/escala de DECIMAL (pero sin excederse)

7. Resumen

MySQL ofrece una amplia variedad de tipos de datos, y el tipo que elija puede afectar significativamente el rendimiento, la escalabilidad y el mantenimiento.
Especialmente en entornos como aplicaciones web donde los datos tienden a crecer, las decisiones de diseño tempranas impactan directamente en la calidad a largo plazo.

Puntos clave de este artículo

• Los tipos de datos son factores críticos que afectan “tipo de valor, rango, precisión, almacenamiento y rendimiento.”
• Los tipos numéricos, de cadena, fecha/hora, JSON, ENUM/SET y BLOB tienen cada uno fortalezas y debilidades.
• Los enteros, cadenas y tipos de fecha/hora se usan con mayor frecuencia, por lo que elegir correctamente es importante.
• JSON y ENUM son convenientes, pero su uso indebido puede dificultar el mantenimiento.
• El uso excesivo de TEXT y BLOB puede degradar el rendimiento.
• Un enfoque de diseño racional es: “Propósito → Rango → Rendimiento → Escalabilidad.”

Una lista de verificación de diseño que puede usar a partir de hoy

• ¿Está claramente definido el propósito de la columna?
• ¿Comprendes los valores máximos y mínimos posibles?
• ¿Hay evidencia que respalde la longitud elegida para VARCHAR?
• ¿Estás usando DECIMAL para el dinero?
• ¿Los timestamps de “updated at” se gestionan con TIMESTAMP y auto‑actualización cuando corresponde?
• Antes de usar ENUM, ¿consideraste que los valores podrían incrementarse en el futuro?
• ¿Estás evitando diseños donde la búsqueda se vuelve lenta por el uso excesivo de JSON?
• ¿Diseñaste para evitar operaciones pesadas de ALTER TABLE en conjuntos de datos grandes?

Finally

No siempre existe una única “respuesta correcta” para elegir los tipos de datos en MySQL.
Sin embargo, si eliges con propósito y pensando en el crecimiento futuro, puedes prevenir problemas mayores y mantener tu estructura de datos limpia.

En última instancia, la mejor elección depende de la naturaleza de tu proyecto, el volumen de datos y los requisitos de la aplicación. Pero si utilizas los criterios presentados en este artículo como base, deberías poder tomar decisiones de tipos de datos más acertadas en cualquier situación.

A continuación, presentaremos una sección de FAQ que resume preguntas frecuentes en el trabajo real.
Cuando no estés seguro sobre la selección de tipos, consultar esta FAQ primero te ayudará a decidir de manera más fluida.

8. FAQ

Elegir tipos de datos en MySQL es un área donde las decisiones pueden variar significativamente según la experiencia del mundo real.
Aquí recopilamos preguntas comunes de equipos de desarrollo y ofrecemos respuestas breves y claras.

Q1. ¿Debería usar INT o BIGINT?

R: Usa INT por defecto. Usa BIGINT solo si podría superar los 2.1 mil millones en el futuro.

INT (4 bytes) soporta hasta aproximadamente 2.1 mil millones y es suficiente para la mayoría de las aplicaciones.
Considera BIGINT para logs, servicios de alto tráfico o sistemas que puedan generar un número extremadamente grande de IDs.

Q2. ¿Debería usar VARCHAR o TEXT?

R: Usa VARCHAR si necesitas buscar. Usa TEXT para contenido extenso.

• VARCHAR : Amigable con índices y mejor para búsquedas
• TEXT : Adecuado para contenido largo pero no ideal para búsquedas o JOINs

※ El uso excesivo de TEXT puede provocar degradación del rendimiento.

Q3. ¿Está bien almacenar dinero como DOUBLE?

R: No. Siempre usa DECIMAL.

DOUBLE y FLOAT pueden introducir errores de redondeo, por lo que no son adecuados para dinero o valores que requieran precisión.
En sistemas empresariales, DECIMAL(10,2) o DECIMAL(12,2) es un estándar común.

Q4. No entiendo la diferencia entre DATETIME y TIMESTAMP. ¿Cómo debería elegir?

R: Usa TIMESTAMP si necesitas auto‑actualizaciones. Usa DATETIME si necesitas almacenar un timestamp preciso sin conversión de zona horaria.

• TIMESTAMP : Auto‑actualización y conversión de zona horaria
• DATETIME : No se ve afectado por zonas horarias; almacena la fecha/hora “tal cual”

DATETIME se usa a menudo para logs y tablas de historial.

Q5. ¿Es seguro usar ENUM?

R: Solo es útil cuando los valores están “garantizados que no cambiarán”.

ENUM es liviano y conveniente, pero agregar o cambiar valores requiere ALTER TABLE.
Para campos que puedan crecer, se recomienda gestión maestra en una tabla separada.

Q6. ¿Puedo usar JSON por ahora?

R: Usa JSON solo para datos que no buscas. Los datos que buscas deben estar normalizados.

JSON es flexible, pero tiene debilidades de rendimiento.

• Débil para búsquedas
• Las estructuras de índices se vuelven más complejas
• Más difícil mantener la consistencia de los datos

Funciona bien para configuraciones y opciones—atributos que no se utilizan como condiciones de búsqueda.

Q7. ¿Cómo debo decidir la longitud máxima para VARCHAR?

R: Estima el máximo basándote en datos reales y añade un pequeño margen.

Ejemplo: Dirección de correo → VARCHAR(100) es suficiente
Ejemplo: Nombre de usuario → VARCHAR(50) suele ser adecuado

“No usar 255 solo porque sí” no es recomendable.

Q8. Si elegí el tipo incorrecto, ¿puedo cambiarlo después?

R: Sí, pero puede ser muy costoso en tablas grandes.

ALTER TABLE a menudo implica escaneos completos y reconstrucciones,
lo que puede causar tiempo de inactividad o bloqueos prolongados.

→ Una planificación cuidadosa en la fase de diseño inicial es lo más importante.