Entrevista de ingeniería de datos: ¿Cómo se usan las columnas invisibles de MySQL para una evolución segura del esquema?

Planteamiento y contexto

Un cliente antiguo depende de SELECT * y de la decodificación posicional de resultados, mientras que un nuevo servicio necesita un campo adicional. Explique cómo una columna INVISIBLE de MySQL 8.4 permite que coexistan clientes antiguos y nuevos, abordando referencias explícitas, valores predeterminados de escritura, índices, copias de seguridad y límites de reversión (rollback).

Qué evalúa el entrevistador

• Si comprende que la invisibilidad cambia la expansión implícita de columnas, no el almacenamiento ni la participación en restricciones.
• Si distingue entre SELECT *, listas explícitas, listas INSERT y CREATE TABLE ... SELECT.
• Si considera claves primarias y únicas, claves foráneas, restricciones check, registro binario (binary logging) y restauración de copias de seguridad.
• Si puede planificar un despliegue gradual, observabilidad y una transición final a consultas VISIBLE.

Preguntas de clarificación que conviene hacer

Confirme la versión de MySQL, el motor de almacenamiento, la topología de replicación, las herramientas de copia de seguridad y si los clientes antiguos realmente decodifican por posición. Pregunte si el nuevo campo necesita un valor predeterminado, participa en una restricción única, es consumido por reportes o CDC, y si debe sobrevivir a una reversión con sus datos intactos.

Respuesta de 30 segundos

Una columna invisible sigue formando parte de la tabla, pero SELECT * y tbl.* la omiten; las referencias explícitas pueden leerla y escribirla. Agregue el campo como INVISIBLE para que la estructura de resultados de los clientes antiguos permanezca estable, mientras que los nuevos clientes utilizan listas explícitas para lecturas y rellenos retroactivos (backfills). Pruebe valores predeterminados, índices únicos, claves foráneas, CDC, restauración de copias de seguridad y la visibilidad en CREATE TABLE ... SELECT. Una vez que todos los consumidores hayan migrado, cambie la visibilidad a VISIBLE. Es una herramienta de compatibilidad, no de autorización o aislamiento de datos.

Análisis detallado paso a paso

1. Confirmar la semántica de las columnas invisibles

En MySQL 8.4, una columna invisible no aparece en los resultados de SELECT *, tbl.* ni TABLE a menos que se nombre explícitamente. No oculta el almacenamiento, los índices ni las restricciones, y no es un control de acceso a nivel de columna.

2. Diseñar un DDL compatible

Utilice ALTER TABLE ... ADD COLUMN ... INVISIBLE y elija un valor predeterminado seguro o un comportamiento NULL para las escrituras antiguas. Mantenga al menos una columna visible. Los nuevos clientes deben comenzar con listas explícitas en lugar de continuar con el contrato *.

3. Validar lecturas, escrituras y restricciones

Los clientes antiguos deben recibir el conjunto de columnas original. Los nuevos clientes leen y escriben explícitamente el campo; una columna invisible omitida recibe el comportamiento predeterminado implícito de MySQL. Las restricciones de clave primaria, única, clave foránea y check siguen aplicándose, por lo que se deben probar duplicados, cascadas y transacciones fallidas.

4. Tener en cuenta la replicación y las canalizaciones de datos

Las columnas invisibles se tratan como columnas visibles en los eventos de fila; su inclusión depende de configuraciones como binlog_row_image. Pruebe CDC, ETL, mapeos ORM y comprobaciones de calidad de datos con listas de columnas reales en lugar de inferir la replicación a partir de SELECT *.

5. Escribir el script de migración más pequeño posible

ALTER TABLE orders
  ADD COLUMN risk_score DECIMAL(5, 2) NULL INVISIBLE;

SELECT order_id, status, risk_score
FROM orders
WHERE order_id = ?;

ALTER TABLE orders
  MODIFY COLUMN risk_score DECIMAL(5, 2) NULL VISIBLE;

Ejecute primero el DDL, despliegue lecturas explícitas y rellenos de datos, observe errores en clientes antiguos y el retraso de CDC, y solo entonces cambie la visibilidad. La planificación de producción también debe evaluar bloqueos, compatibilidad con online-DDL y la ventana de reversión.

6. Comprobar copias de seguridad, creación de tablas y restauración

mysqldump y SHOW CREATE TABLE preservan los metadatos de invisibilidad. Restaurar en un servidor más antiguo que no admita la función puede hacer que la columna sea visible porque se ignoran los comentarios de versión. Una columna invisible explícita en CREATE TABLE ... SELECT puede volverse visible en el destino a menos que la definición repita INVISIBLE.

Respuesta de ejemplo de alta calidad

Trataría una columna invisible como una herramienta de compatibilidad, no como un límite de seguridad. Primero verificaría que los clientes antiguos realmente dependan de SELECT *, luego agregaría una columna INVISIBLE con semántica anulable o de valor predeterminado seguro mediante una ruta de DDL en línea. Los clientes antiguos mantienen su estructura de resultados original; los nuevos clientes deben usar listas explícitas para lecturas, rellenos de datos y escrituras. Las pruebas cubren valores predeterminados, actualizaciones explícitas, conflictos primarios y únicos, claves foráneas y comprobaciones check, mapeos ORM, comportamiento de CDC bajo binlog_row_image, restauración de copias de seguridad y visibilidad en CREATE TABLE ... SELECT. Durante la migración, supervise la tasa de errores, el retraso de replicación y la integridad de los datos. Una vez que todos los consumidores utilicen un contrato explícito estable, cambie el campo a VISIBLE. Una reversión puede restaurar la versión de la aplicación conservando la columna y los datos; la restauración entre distintas versiones requiere verificar la compatibilidad y los metadatos del dump. A largo plazo, elimine SELECT * para que el contrato de resultados sea explícito.

Errores comunes

• Asumir que las columnas invisibles no participan en claves, comprobaciones check, claves foráneas o registro binario.
• Probar únicamente SELECT * y omitir lecturas explícitas, escrituras y mapeos ORM.
• Tratar la invisibilidad como permisos de columna, privacidad o aislamiento de datos.
• Ignorar CREATE TABLE ... SELECT, la restauración de dumps y el comportamiento en servidores más antiguos.
• Continuar usando SELECT * en clientes nuevos y recrear el problema de compatibilidad más adelante.

Preguntas de seguimiento y respuestas

¿Resuelve una columna invisible todos los problemas de compatibilidad con SELECT *?

No. Estabiliza el conjunto devuelto, pero la decodificación posicional, la reflexión de ORM, los reportes y el CDC aún requieren validación individual. La solución a largo plazo consiste en utilizar listas de columnas explícitas.

¿Qué sucede en un insert cuando se omite la columna invisible?

Recibe el comportamiento predeterminado implícito de MySQL. Para escribir un valor específico, nombre la columna explícitamente y pruebe NOT NULL, restricciones únicas y check.

¿Cuándo se debe volver a cambiar a VISIBLE?

Después de que las lecturas, escrituras, CDC, copias de seguridad y reportes utilicen un contrato explícito estable, y se superen las pruebas de monitoreo y reversión. Luego cambie la visibilidad en un despliegue gradual.