En enero de 2003, cuando este artículo se publicó por primera vez (cedido por MySQL Hispano), MySQL 4.0 acababa de alcanzar la versión estable tras dos años de desarrollo. Era un momento clave: por primera vez InnoDB venía activado por defecto, había soporte SSL nativo y se añadía la caché de consultas. Poco imaginábamos que veintitrés años después MySQL seguiría siendo el servidor de bases de datos open source más usado del mundo. Esta edición, actualizada por David Carrero en 2026, conserva el artículo original y añade la perspectiva histórica de lo que ocurrió después.
MySQL 4.0: las novedades de 2003
La versión 4.0 de MySQL estuvo en desarrollo desde 2001. El trabajo se centró en tres frentes: mejorar características existentes, añadir funcionalidades nuevas y refactorizar la arquitectura interna para el crecimiento futuro.
Mejoras desde MySQL 3.23
- El optimizador de consultas aprendió a usar índices de forma más inteligente. Algunas consultas con ordenación extra pasaron a ser significativamente más rápidas.
- Las opciones de los índices FULLTEXT (como la longitud mínima de palabra) se movieron al fichero de configuración, eliminando la necesidad de recompilar MySQL para cambiarlas.
- Cambios en el código de la caché de claves produjeron un incremento notable de rendimiento en consultas basadas en índices bajo alta carga.
- MySQL 4.0 introdujo las eliminaciones multi-tabla: con la cláusula WHERE correcta se podían borrar registros relacionados de varias tablas en una sola sentencia DELETE.
- El sistema de replicación se volvió multi-hilo en los servidores esclavos, mejorando enormemente la tolerancia a fallos del maestro.
- El número de variables de estado casi se duplicó, ofreciendo una visión mucho más detallada del interior de MySQL.
InnoDB: transacciones ACID en el núcleo de MySQL
La gran novedad de MySQL 4.0 fue incluir InnoDB en la instalación estándar. Hasta entonces era una extensión opcional. MySQL soportaba cinco tipos de tabla: MyISAM, ISAM, HEAP, BDB e InnoDB, aunque solo BDB e InnoDB eran transaccionales.
InnoDB aportaba algo que MyISAM nunca tuvo:
- Recuperación automática ante fallos. Si MySQL se caía de forma anormal, InnoDB completaba o revertía las transacciones incompletas al arrancar.
- Integridad referencial. Se podían definir claves foráneas entre tablas InnoDB para evitar registros huérfanos.
- Bloqueo a nivel de fila. MyISAM bloqueaba la tabla completa en escrituras. InnoDB solo bloqueaba las filas afectadas, mejorando el rendimiento con escrituras concurrentes.
- SELECTs sin bloqueo. El motor usaba multi-versioning (MVCC) para permitir lecturas sin interferir con escrituras en curso.
Crear una tabla InnoDB en 2003 requería especificar el tipo explícitamente. La sintaxis era:
CREATE TABLE algunaTabla ( campoX INTEGER UNSIGNED AUTO_INCREMENT PRIMARY KEY, campoY INTEGER NOT NULL, campoZ VARCHAR(255) NOT NULL ) TYPE = InnoDB;
(Nota: en MySQL 5.5 se cambió TYPE por ENGINE, que es la sintaxis correcta desde entonces.)
Soporte SSL nativo
Hasta MySQL 4.0, cifrar la conexión entre cliente y servidor requería configurar un túnel SSH o stunnel de forma externa. La versión 4.0 integró SSL directamente en el protocolo de MySQL.
El soporte SSL se integró en el sistema de privilegios. Para obligar a un usuario a conectarse solo por SSL:
GRANT ALL PRIVILEGES ON bd_abc.* TO juancho@'%' IDENTIFIED BY 'holahola' REQUIRE SSL;
Para exigir además un certificado X.509 válido:
GRANT ALL PRIVILEGES ON bd_abc.* TO juancho@'%' IDENTIFIED BY 'holahola' REQUIRE X509;
La caché de consultas
Una de las incorporaciones más esperadas en MySQL 4.0 fue la caché de consultas (query cache). Almacenaba en memoria los resultados de las consultas SELECT recientes. Si la misma consulta se repetía y los datos no habían cambiado, MySQL devolvía el resultado cacheado sin ejecutar la consulta.
-- Configuración en my.cnf (MySQL 4.0 - 5.7) query_cache_size = 64M query_cache_type = 1
Para sitios web con muchas lecturas y pocas escrituras (portales de noticias, catálogos de productos) la mejora era espectacular. Sin embargo, la caché tenía una limitación grave: en tablas con escrituras frecuentes, MySQL invalidaba constantemente los segmentos cacheados, convirtiendo la caché en overhead puro. En cargas de trabajo mixtas, desactivarla daba mejor rendimiento que activarla.
Nota histórica: la caché de consultas, que llegó con MySQL 4.0, fue eliminada definitivamente en MySQL 8.0. Oracle consideró que su arquitectura era incompatible con el paralelismo moderno. Para cachear en 2026 se usan soluciones externas como Redis o Memcached.
UNION: combinar resultados de varias consultas
MySQL 4.0 añadió la sentencia UNION, que permite combinar los resultados de varios SELECT en un único conjunto de filas:
(SELECT id, balance FROM cuentas WHERE fecha_est = '2002-10-04') UNION (SELECT id, balance FROM cuentas_anteriores WHERE fecha_est = '2002-10-04');
Lo que venía en MySQL 4.1
Al cierre del artículo original, las siguientes características estaban previstas para 4.1:
- Subconsultas (subqueries).
- Ayuda integrada en el cliente
mysql. - Nuevo formato de definición de tablas.
- Claves foráneas para tablas MyISAM.
- Replicación fail-safe.
- Soporte más estable de OpenSSL.
De MySQL 4.0 a MySQL 8: veintitrés años de evolución
Desde 2003, MySQL ha recorrido un largo camino. Esta es la línea temporal de los hitos más importantes:
Versión | Año | Novedades clave |
4.1 | 2004 | Subconsultas, soporte Unicode (UTF-8), prepared statements |
5.0 | 2005 | Stored procedures, triggers, vistas, INFORMATION_SCHEMA |
5.1 | 2008 | Particionado de tablas, event scheduler, mejoras en replicación |
5.5 | 2010 | InnoDB como motor por defecto, PERFORMANCE_SCHEMA, utf8mb4 |
5.6 | 2013 | FULLTEXT en InnoDB, mejoras en el optimizador, replicación GTID |
5.7 | 2015 | JSON nativo, generadas columnas, mejoras InnoDB, sys schema |
8.0 | 2018 | Window functions, CTEs, roles, utf8mb4 por defecto, eliminación query cache |
8.18.4 | 20232024 | Ciclo de versiones de innovación, mejoras incrementales en InnoDB y replicación |
MySQL 8 en 2026: qué traen los 23 años de mejoras
Si el desarrollador de 2003 pudiera ver MySQL 8, no reconocería muchas cosas:
Window functions
Permiten cálculos sobre ventanas de filas sin colapsar el resultado como hace GROUP BY. Imprescindibles para análisis:
SELECT cliente_id, fecha_pedido, importe, SUM(importe) OVER (PARTITION BY cliente_id ORDER BY fecha_pedido) AS acumulado FROM pedidos;
CTEs (Common Table Expressions)
Las CTEs con WITH permiten consultas recursivas y hacen el SQL mucho más legible:
WITH ventas_mensuales AS (
SELECT DATE_FORMAT(fecha_pedido, '%Y-%m') AS mes,
SUM(importe) AS total
FROM pedidos
GROUP BY mes
)
SELECT mes, total,
total - LAG(total) OVER (ORDER BY mes) AS variacion
FROM ventas_mensuales;
JSON nativo
MySQL 5.7 introdujo un tipo de columna JSON con validación, y MySQL 8 amplió las funciones disponibles. Ideal para datos semi-estructurados sin romper la normalización del esquema principal:
ALTER TABLE productos ADD COLUMN atributos JSON;
UPDATE productos SET atributos = '{"color": "rojo", "talla": "XL"}' WHERE id_producto = 42;
SELECT nombre FROM productos
WHERE JSON_VALUE(atributos, '$.color') = 'rojo';
Roles
MySQL 8 introdujo roles, que agrupan privilegios y simplifican la gestión de usuarios en equipos grandes:
CREATE ROLE 'desarrollador'; GRANT SELECT, INSERT, UPDATE ON tienda.* TO 'desarrollador'; GRANT 'desarrollador' TO 'juan'@'localhost'; SET DEFAULT ROLE 'desarrollador' TO 'juan'@'localhost';
utf8mb4 por defecto
El charset utf8 de MySQL siempre fue un truco: solo almacenaba hasta 3 bytes por carácter, excluyendo emojis y muchos caracteres CJK. MySQL 8 cambió el charset por defecto a utf8mb4, el UTF-8 real. Si estás en MySQL 5.x con utf8, migra a utf8mb4 para evitar problemas con caracteres especiales.
InnoDB: de opcional a imprescindible
El mayor cambio conceptual desde 2003 es que InnoDB dejó de ser una opción avanzada para convertirse en el único motor de propósito general que tiene sentido usar. MyISAM sigue presente en MySQL 8 para tablas internas del sistema, pero no debería usarse en aplicaciones nuevas. BDB desapareció en MySQL 5.1. La caché de consultas que llegó con MySQL 4.0 se fue con MySQL 8.0.
De todas las características que MySQL 4.0 introdujo en 2003, InnoDB es la que más ha crecido y más impacto ha tenido. El artículo original la presentaba como una novedad prometedora. En 2026 es la columna vertebral de MySQL.
Imagen: Pexels / luis gomes