Triggers en MySQL (disparadores)

Un trigger es un bloque de código SQL que se ejecuta automáticamente al ocurrir un evento INSERT, UPDATE o DELETE sobre una tabla. Son muy útiles para mantener la integridad de los datos, auditar cambios y automatizar reglas de negocio.

¿Qué es un Trigger? Tipos y sintaxis

Un trigger se asocia a una tabla y se define para ejecutarse antes (BEFORE) o después (AFTER) de un evento INSERT, UPDATE o DELETE.

CREATE TRIGGER nombre_trigger
{BEFORE | AFTER} {INSERT | UPDATE | DELETE}
ON nombre_tabla
FOR EACH ROW
BEGIN
    -- instrucciones SQL
END;

FOR EACH ROW es obligatorio. Significa que el trigger se ejecutará una vez por cada fila afectada por la sentencia DML. No existe en MySQL el nivel FOR EACH STATEMENT (por sentencia).

Usos principales de los triggers (Auditoría, Validación, Automatización)

Desde los inicios, los triggers se han usado para tres propósitos fundamentales. A continuación se detallan con ejemplos conceptuales:

• Auditoría: Registrar cambios en una tabla de historial sin modificar los datos originales. Ej: un trigger AFTER UPDATE que inserta en `auditoria_productos` los valores antiguos y nuevos.
• Validación: Asegurar que los datos cumplan reglas de negocio antes de ser insertados o actualizados. Ej: un trigger BEFORE INSERT que verifique que el precio no sea negativo, y si lo es, lanza un SIGNAL.
• Automatización: Realizar cálculos o actualizaciones automáticas basadas en cambios. Ej: el trigger BEFORE UPDATE que duplica el precio cuando cambia el costo.

Estos usos se pueden combinar, pero es importante no mezclar lógica que pueda causar efectos secundarios no deseados. La sección "Automatización vs Auditoría" más abajo muestra dos triggers distintos sobre la misma tabla para que veas la diferencia.

Ejemplo clásico: automatización de precio (BEFORE UPDATE)

Tabla productos y trigger que actualiza el precio automáticamente cuando el costo cambia.

CREATE TABLE productos (
    id INT PRIMARY KEY,
    nombre VARCHAR(100),
    costo DECIMAL(10,2),
    precio DECIMAL(10,2),
    proveedor_id INT
);

DELIMITER $$
CREATE TRIGGER actualizarPrecioProducto
BEFORE UPDATE ON productos
FOR EACH ROW
BEGIN
    IF NEW.costo <> OLD.costo THEN
        SET NEW.precio = NEW.costo * 2;
    END IF;
END$$
DELIMITER ;

Visualización paso a paso (aclaración sobre el momento de ejecución)

Importante: Cuando ejecutamos UPDATE productos SET costo = costo * 1.10 WHERE proveedor_id = 1;, el motor:

1. Calcula en memoria el nuevo valor de costo para cada fila afectada (ej: 50 → 55).
2. Antes de escribir cualquier cambio en la tabla, ejecuta el trigger BEFORE UPDATE para esa fila. Dentro del trigger, OLD contiene los valores actuales (aún intactos en la tabla) y NEW contiene los valores calculados (aún no escritos).
3. El trigger puede modificar NEW.precio.
4. Una vez que el trigger termina, se escribe la fila completa con los valores finales de NEW.

Tabla de evolución paso a paso (fila por fila)

Partimos de los siguientes registros iniciales:

Ejecutamos: UPDATE productos SET costo = costo * 1.10 WHERE proveedor_id = 1; (afecta id=1 y id=2).

Tabla productos después del UPDATE (estado final):

NEW y OLD en profundidad

• NEW: Disponible en INSERT y UPDATE. Contiene los nuevos valores que se van a insertar o actualizar. Se puede modificar solo en triggers BEFORE.
• OLD: Disponible en UPDATE y DELETE. Contiene los valores antiguos (antes del cambio o los que se eliminan). Es de solo lectura.

En INSERT, OLD no existe. En DELETE, NEW no existe.

Casos donde no necesitamos usar NEW u OLD (ejemplos del PDF original)

Existen situaciones donde el trigger no requiere acceder a los valores específicos de la fila, sino solo a la operación en sí.

CREATE TRIGGER after_insert_log
AFTER INSERT ON tablita
FOR EACH ROW
BEGIN
    INSERT INTO log_auditoria (accion_ejecutada, nombre_tabla, fecha_hora)
    VALUES ('INSERT', 'tablita', NOW());
END;

CREATE TRIGGER before_delete_limpieza
BEFORE DELETE ON pedidos
FOR EACH ROW
BEGIN
    DELETE FROM detalle_pedido WHERE id_pedido = OLD.id_pedido;
END;

CREATE TRIGGER after_delete_cleanup
AFTER DELETE ON employees
FOR EACH ROW
BEGIN
    DELETE FROM employee_history WHERE employee_id = OLD.employee_id;
END;

Disponibilidad de NEW y OLD según la operación

• INSERT: Solo NEW disponible.
• UPDATE: Tanto NEW como OLD disponibles.
• DELETE: Solo OLD disponible.

¿Son tablas o CTEs? No. NEW y OLD son referencias temporales a los datos de una fila específica durante la ejecución del trigger. No existen físicamente, no ocupan espacio, y no se pueden consultar fuera del trigger.

Qué SÍ y qué NO se puede hacer dentro de un trigger (tabla ampliada)

Automatización vs Auditoría (dos triggers sobre la misma tabla)

Ejemplo con tabla pedidos y campo estado:

CREATE TABLE pedidos (
    id INT PRIMARY KEY,
    cliente VARCHAR(100),
    estado VARCHAR(20),
    fecha_entrega DATE
);
CREATE TABLE auditoria_pedidos (
    id INT AUTO_INCREMENT PRIMARY KEY,
    pedido_id INT,
    estado_anterior VARCHAR(20),
    estado_nuevo VARCHAR(20),
    usuario VARCHAR(50),
    fecha_cambio TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TRIGGER auto_fecha_entrega
BEFORE UPDATE ON pedidos FOR EACH ROW
BEGIN
    IF NEW.estado = 'enviado' AND OLD.estado != 'enviado' THEN
        SET NEW.fecha_entrega = CURDATE();
    END IF;
END;

CREATE TRIGGER audit_estado_pedido
AFTER UPDATE ON pedidos FOR EACH ROW
BEGIN
    INSERT INTO auditoria_pedidos (pedido_id, estado_anterior, estado_nuevo, usuario)
    VALUES (NEW.id, OLD.estado, NEW.estado, USER());
END;

Múltiples triggers para el mismo evento: mala práctica

• Orden de ejecución no garantizado (incluso con FOLLOWS/PRECEDES).
• Fragiliza el mantenimiento y la depuración.
• Usa un único trigger por evento/momento y centraliza la lógica.

Consideraciones de rendimiento y limitaciones adicionales

• Solo nivel fila: Actualizar 10.000 filas ejecuta el trigger 10.000 veces. Cuidado con operaciones masivas.
• No se puede modificar un trigger directamente: Hay que hacer DROP y CREATE (no existe ALTER TRIGGER).
• Depuración compleja: Los errores se reportan como si vinieran de la sentencia DML.
• Recursividad potencial: Puede controlarse con max_sp_recursion_depth.
• Caché de definición: Si se altera una tabla referenciada, puede requerirse FLUSH TABLES o reinicio.
• Permisos: Se necesita el privilegio TRIGGER sobre la tabla.

Administración y consulta de triggers

-- Ver todos los triggers de la BD actual
SHOW TRIGGERS;

-- Ver triggers de una BD específica
SHOW TRIGGERS FROM nombre_base_datos;

-- Ver triggers de una tabla específica
SHOW TRIGGERS FROM tienda WHERE `Table` = 'productos';

-- Consultar usando INFORMATION_SCHEMA (más potente)
SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_TIMING, ACTION_STATEMENT
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE TRIGGER_SCHEMA = 'nombre_base_datos';

-- Eliminar trigger
DROP TRIGGER IF EXISTS nombre_trigger;

El comando SHOW TRIGGERS devuelve columnas como: Trigger, Event, Table, Statement, Timing, Created, definer, etc.

Preguntas frecuentes (FAQ)

Documento completo basado en MySQL 8.0. Incluye todos los conceptos del material original: definición, tipos BEFORE/AFTER, sintaxis, ejemplo, NEW/OLD, usos (auditoría, validación, automatización), ejemplos visuales paso a paso (con tablas de evolución), casos sin NEW/OLD, disponibilidad por operación, tabla de capacidades, limitaciones, administración y preguntas frecuentes. Corregido el error del precio del mouse (66.00).