Este grave bug sin resolver en una de las bases de datos más usadas ya es más viejo que muchos desarrolladores que la usan

Publicado el 27/06/2025 por Diario Tecnología Artículo original

En junio de 2005, el mundo del software era muy distinto: YouTube acababa de nacer, PHP dominaba la web y MySQL era la opción de base de datos preferida de muchos desarrolladores por su velocidad y simplicidad. En ese mismo mes, se reportó un bug en este último software que, 20 años después, contra toda previsión, sigue sin solucionarse.

Hoy, esta anomalía no solo amenaza la integridad de los datos gestionados con MySQL, sino que también se ha convertido en un símbolo del estancamiento tecnológico y de la desconfianza creciente hacia este sistema de gestión de bases de datos... que sigue siendo el segundo más usado globalmente.

El bug #11472: una bomba de tiempo en la integridad de los datos

El bug en cuestión se trata de una vulnerabilidad grave (sólo un peldaño por debajo de la máxima categoría, 'crítica') relacionada con los 'triggers' o disparadores de la base de datos. Pero, ¿qué es un 'trigger'?

Pongámonos en situación: imagina que tienes una hoja de cálculo, y que cada vez que escribes algo en una celda, automáticamente se actualiza otra celda con un nuevo valor. Eso es, en esencia, lo que hace un disparador en una base de datos.

Su función más común es ayudar a mantener la coherencia y seguridad de la información: por ejemplo, si borras una cuenta de usuario, un 'trigger' podría asegurarse de que también se borren sus publicaciones o su historial de navegación.

¿Entonces cuál es el problema?

El famoso bug #11472 provoca que los 'triggers' no se activen cuando la modificación de los datos ocurre de forma indirecta, a través de lo que se conoce como una clave foránea (foreign key).

Las claves foráneas sirven para conectar dos tablas entre sí. Por ejemplo:

• Tienes una tabla llamada 'Clientes' y otra llamada 'Pedidos'.
• Cada pedido está vinculado a un cliente concreto mediante una clave foránea.

Si borras un cliente, puede configurarse el sistema para que automáticamente se borren todos sus pedidos. Esto se denomina 'eliminación en cascada'.

Pero aquí es donde el bug entra en escena: si hay un 'trigger' que debería ejecutarse cuando se borra un pedido (por ejemplo, para restar ese pedido del total de ingresos), no se activa si ese pedido no fue borrado directamente, sino como consecuencia indirecta de haber eliminado al cliente. Es decir, el 'trigger' falla en hacer su trabajo sin que nadie lo note.

¿Por qué es esto tan grave?

Porque rompe un principio clave de las bases de datos: la integridad de los datos. En otras palabras, podrías pensar que tu sistema está llevando correctamente un control de los datos cuando en realidad hay procesos importantes que nunca se ejecutan.

Este error puede hacer que tus estadísticas estén mal, que tus cálculos financieros sean incorrectos, o que pierdas datos esenciales. Y lo peor: no te darás cuenta, porque no se genera un error visible. El trigger, simplemente, no se da por aludido.

Dos décadas de promesas incumplidas

Cuando se denunció el problema hace ya dos décadas, el equipo de desarrollo de MySQL reconoció su existencia y prometió resolverlo en la inminente versión 5.1. Sin embargo, esa solución jamás llegó. La única 'respuesta' oficial fue incluir una nota en la documentación que admite que "las acciones en cascada de claves foráneas no activan triggers".

La frustración de la comunidad ha sido tangible: en 2015, en los comentarios oficiales del bug, un usuario escribió:

"Acabamos de empezar a sufrir este problema al implementar 'triggers' sobre eliminaciones en cascada. Por favor, se agradecería mucho que dieran una solución".

Pero mucho más lapidario fue este otro comentario publicado en 2020:

"Este bug es más viejo que yo".

¿Negligencia o qué?

Aunque el bug fue reportado mucho antes de que Oracle adquiriera MySQL en 2010, muchos ven su persistencia como reflejo de un abandono sistemático del proyecto. Incluso voces respetadas como la de Peter Zaitsev, cofundador de Percona y exingeniero de MySQL, han acusado a Oracle de "descuidar el rendimiento de MySQL" y reservar las innovaciones para su versión en la nube, Heatwave.

Algunos defensores de mantener el bug abierto argumentan que cambiar el comportamiento ahora podría romper sistemas que, tras 20 años, han aprendido a vivir con esta limitación. Pero en este caso, esa defensa resulta bastante débil: es poco probable que alguien dependa conscientemente de que un 'trigger' no se ejecute cuando debería.

El éxodo hacia PostgreSQL

Este bug ha sido la gota que colmó el vaso para muchas empresas, para las que este bug ha sido la gota que ha colmado el vaso y provocado su abandono de MySQL.

Según los rankings, MySQL sigue siendo el segundo sistema de bases de datos más utilizado del mundo, solo por detrás del software privativo Oracle, y todavía por delante de Microsoft SQL Server. Pero la tendencia es clara: su popularidad está en descenso, mientras que PostgreSQL asciende rápidamente.

Aunque estas métricas se basan en menciones y ofertas laborales más que en uso real, no dejan de ser un termómetro del sentir del ecosistema tecnológico.

Otro termómetro son los foros como Reddit, donde proliferan las recomendaciones de migrar a PostgreSQL, y comentarios como "La solución no es usar triggers de otra forma, es usar una base de datos relacional decente".

De hecho, PostgreSQL se ha convertido en el refugio más común para quienes huyen de MySQL. Su respeto riguroso por las reglas ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) y su activa comunidad lo han posicionado como una alternativa fiable.

¿Qué deben hacer los usuarios de MySQL?

Las organizaciones que aún dependen de MySQL —especialmente si usan triggers como parte de sus políticas de integridad— deberían tomar cartas en el asunto:

• Auditar sus implementaciones de 'triggers': verificar si su lógica depende de eventos en cascada que podrían no estar siendo gestionados correctamente.
• Buscar métodos alternativos de integridad referencial, como control a nivel de aplicación.
• Evaluar migraciones a otros motores como PostgreSQL, donde el cumplimiento de los principios de integridad es más riguroso.
• Monitorizar los canales oficiales de MySQL para detectar cualquier intento de solución, aunque la historia reciente no da muchas esperanzas.

Imagen | Marcos Merino mediante IA

En Genbeta | Las cuatro mejores plataformas gratis para practicar SQL, el lenguaje de bases de datos por excelencia 

utm_campaign=27_Jun_2025"> Marcos Merino .