Readyset.io ha publicado un análisis profundo sobre un cambio significativo en MySQL 9.6 que aborda una limitación arquitectónica de larga data. Históricamente, MySQL ha manejado las restricciones de clave foránea (foreign keys) dentro del motor de almacenamiento InnoDB, lo que significaba que las operaciones en cascada (ON DELETE CASCADE, ON UPDATE CASCADE) eran invisibles para la capa SQL y, crucialmente, no se registraban en el registro binario (binary log). Esto ha generado problemas en entornos de replicación y, especialmente, en herramientas de captura de datos de cambios (CDC) como Readyset, Debezium, y otras.
El problema radica en que, con la implementación anterior, cuando se eliminaba un registro en una tabla padre, InnoDB ejecutaba las operaciones en cascada en las tablas hijas internamente, sin que la capa SQL supiera nada de ello. Esto dejaba un registro binario incompleto, omitiendo las eliminaciones de los registros hijos. Esto afectaba a la replicación (especialmente cuando se usaban motores de almacenamiento distintos a InnoDB) y a las herramientas CDC, que dependen del registro binario para capturar todos los cambios. Además, dificultaba la auditoría completa de las modificaciones de datos.
MySQL 9.6 introduce una solución fundamental: el desplazamiento de la ejecución de las restricciones de clave foránea y las operaciones en cascada a la capa SQL. Ahora, cuando se realiza una eliminación o actualización, la capa SQL evalúa las restricciones, ejecuta las cascadas como sentencias DML separadas y registra todas las operaciones (tanto la operación principal como las cascadas) en el registro binario. Esto proporciona una visibilidad completa de todos los cambios de datos a las réplicas, herramientas CDC y sistemas de auditoría.
Para facilitar la migración, MySQL 9.6 introduce una variable de inicio de sesión innodb_native_foreign_keys que permite revertir al comportamiento anterior si es necesario. Oracle ha indicado que esta variable se eliminará en una futura versión. Las pruebas de rendimiento indican que este cambio tiene un impacto mínimo en el rendimiento, ya que la carga de trabajo subyacente (verificación de restricciones y modificaciones de filas) sigue siendo la misma, solo ha cambiado el punto de ejecución.
En resumen, MySQL 9.6 cierra una brecha arquitectónica importante, proporcionando una solución a un problema que ha afectado a los usuarios de MySQL durante años y mejorando significativamente la integridad y la auditabilidad de los datos.