SHOW WARNINGS

SHOW WARNINGS muestra todos los diagnósticos generados por la última sentencia ejecutada, incluyendo los tres niveles que MySQL distingue: errores, advertencias y notas. Es la versión más completa de las sentencias de inspección, y resulta más informativa que SHOW ERRORS, que se limita a los errores.

Su importancia es a menudo subestimada. Muchas operaciones en MySQL "tienen éxito" pero dejan advertencias por el camino: un dato que se insertó recortado porque no cabía en la columna, una conversión de tipo implícita con pérdida de información, o un valor incorrecto que se ajustó silenciosamente. Si nunca consultas las advertencias, esos problemas pasan desapercibidos hasta que provocan inconsistencias difíciles de rastrear. Por eso, revisar SHOW WARNINGS después de operaciones delicadas es una buena práctica. En este artículo veremos los niveles de diagnóstico, ejemplos de advertencias y notas reales, cómo controlar la generación de notas y cómo acceder a esta información desde procedimientos.

Sintaxis

Al igual que SHOW ERRORS, esta sentencia admite ver todos los diagnósticos, limitarlos con LIMIT o contarlos. La estructura es la misma, cambiando la palabra WARNINGS.

-- Ver todas las advertencias
SHOW WARNINGS;
 
-- Limitar resultados
SHOW WARNINGS LIMIT cantidad;
 
-- Con offset
SHOW WARNINGS LIMIT offset, cantidad;
 
-- Contar advertencias
SHOW COUNT(*) WARNINGS;

Conviene recordar que, como toda sentencia de diagnóstico, se refiere únicamente a la última instrucción ejecutada. Hay que consultarla inmediatamente después de la operación que quieres revisar.

Niveles de diagnóstico

MySQL clasifica cada mensaje de diagnóstico en uno de tres niveles, y SHOW WARNINGS los muestra todos. Entender la diferencia entre ellos es clave para interpretar correctamente la salida.

La distinción crucial es que un Error impide que la operación se complete, mientras que un Warning indica que sí se completó, aunque con alguna incidencia que podría haber alterado los datos. Las Note son meramente informativas y nunca representan un problema.

Ejemplo: advertencia por truncamiento

El caso más ilustrativo de advertencia es el truncamiento de datos. Si intentamos insertar una cadena más larga de lo que admite una columna, MySQL no rechaza la fila: la recorta y emite una advertencia. Para verlo, creamos una tabla temporal con una columna muy corta e insertamos un texto que no cabe.

CREATE TEMPORARY TABLE tmp_test (nombre VARCHAR(5));
INSERT INTO tmp_test VALUES ('MySQL Tutorial');
-- Warning: Data truncated for column 'nombre'
 
SHOW WARNINGS;

La advertencia nos avisa de que el dato se ha truncado en la columna nombre:

Si ahora consultamos la tabla, comprobamos que efectivamente la fila se insertó, pero con el valor recortado a los cinco caracteres que cabían:

SELECT * FROM tmp_test;

El dato se insertó pero truncado a 5 caracteres, lo que demuestra por qué ignorar las advertencias puede llevar a una pérdida silenciosa de información. Limpiamos la tabla temporal cuando terminamos:

DROP TEMPORARY TABLE tmp_test;

Ejemplo: nota con IF EXISTS

Las notas aparecen en situaciones inocuas, como intentar eliminar con IF EXISTS una tabla que no existe. La operación no falla (de eso se encarga el IF EXISTS), pero MySQL deja constancia de que el objeto no estaba mediante una nota.

DROP TABLE IF EXISTS tabla_que_no_existe;
-- Query OK, 0 rows affected, 1 warning
 
SHOW WARNINGS;

No es un error ni una advertencia, solo una nota informativa. Por eso este mensaje aparecería en SHOW WARNINGS pero nunca en SHOW ERRORS.

warning_count

Cuando solo quieres saber cuántos diagnósticos hubo, sin ver el detalle, puedes consultar la variable de sesión correspondiente. Es práctica para comprobaciones rápidas dentro de scripts.

-- Variable de sesión con el conteo
SELECT @@warning_count;

El mismo número se obtiene con la forma de recuento de la sentencia, que resulta equivalente:

-- Equivalente
SHOW COUNT(*) WARNINGS;

sql_notes

Si las notas te resultan ruidosas (por ejemplo, en scripts con muchos DROP ... IF EXISTS), puedes desactivar su generación con la variable sql_notes. Al ponerla a cero, MySQL deja de registrar las notas, aunque sigue generando errores y advertencias.

-- Desactivar notas
SET sql_notes = 0;
 
DROP TABLE IF EXISTS tabla_inexistente;
SHOW WARNINGS;
-- (vacío, no se generó la nota)
 
-- Reactivar
SET sql_notes = 1;

Conviene reactivarla al terminar, porque las notas pueden aportar información útil en otros contextos. Desactivarla es una optimización puntual, no algo que debas dejar permanentemente.

Advertencias comunes

Esta tabla recoge las advertencias y notas que aparecen con más frecuencia, junto con su causa. Tenerlas identificadas te ayuda a reaccionar rápido cuando SHOW WARNINGS devuelve alguna de ellas. Para comparar con los errores propiamente dichos, consulta el artículo de SHOW ERRORS.

Las tres primeras (truncamiento, valor incorrecto y conversión con pérdida) son las que más atención merecen, porque pueden alterar tus datos sin que la operación falle.

Usar SHOW WARNINGS en procedimientos

Dentro de un procedimiento, no usas SHOW WARNINGS directamente, pero sí puedes apoyarte en la variable @@warning_count para detectar si una operación dejó avisos y reaccionar en consecuencia. El siguiente procedimiento comprueba el contador tras una operación que puede generar advertencias.

DELIMITER //
 
CREATE PROCEDURE operacion_con_warnings()
BEGIN
    DECLARE v_warnings INT;
 
    -- Operación que puede generar warnings
    DROP TABLE IF EXISTS tmp_no_existe;
 
    -- Verificar si hubo warnings
    SELECT @@warning_count INTO v_warnings;
 
    IF v_warnings > 0 THEN
        SELECT CONCAT('Se generaron ', v_warnings, ' advertencia(s)') AS info;
    END IF;
END //
 
DELIMITER ;

Este patrón es útil para registrar o reportar que algo no salió perfecto, aunque la operación no llegara a fallar. Eso sí, ten en cuenta que cada nueva sentencia reinicia el contador, así que debes leerlo justo después de la operación que te interesa.

SHOW WARNINGS vs GET DIAGNOSTICS

Cuando trabajas dentro de procedimientos, conviene saber qué herramienta encaja mejor. La siguiente tabla compara SHOW WARNINGS, orientada al uso interactivo, con GET DIAGNOSTICS, pensada para el código almacenado.

Para el manejo de diagnósticos dentro de procedimientos, GET DIAGNOSTICS es claramente más adecuado, ya que permite capturar tanto el número de condiciones como sus detalles en variables. El siguiente ejemplo cuenta las advertencias dentro de un handler para SQLWARNING.

DELIMITER //
 
CREATE PROCEDURE ejemplo_diagnostics()
BEGIN
    DECLARE v_count INT;
 
    DECLARE CONTINUE HANDLER FOR SQLWARNING
    BEGIN
        GET DIAGNOSTICS v_count = NUMBER;
        SELECT CONCAT(v_count, ' advertencia(s) capturada(s)') AS info;
    END;
 
    -- Operación que genera warning
    DROP TABLE IF EXISTS otra_tabla_inexistente;
END //
 
DELIMITER ;

Aquí, el handler SQLWARNING se activa cuando la operación genera una advertencia, y GET DIAGNOSTICS recupera cuántas condiciones hubo, todo sin salir del flujo del procedimiento.

Errores comunes

El error más habitual es no consultar nunca las advertencias y dar por buena cualquier operación que no devuelva un error. Como hemos visto, un truncamiento de datos no falla, pero corrompe la información: revisar SHOW WARNINGS tras inserciones y actualizaciones delicadas evita sorpresas. Para que estos casos sí fallen en lugar de avisar, muchos entornos de producción activan el modo SQL estricto, que convierte ciertos truncamientos en errores.

Otro descuido frecuente es leer el contador de advertencias demasiado tarde. Como cualquier sentencia que genere diagnósticos reinicia la lista, si ejecutas otra instrucción entre la operación y la consulta del contador, obtendrás el recuento de la sentencia equivocada.

Cuándo usar SHOW WARNINGS

Usa SHOW WARNINGS siempre que quieras una visión completa de lo que ocurrió en la última sentencia, especialmente para detectar advertencias silenciosas tras inserciones, actualizaciones o cargas masivas de datos. Cuando solo te interesan los fallos que impidieron completar la operación, SHOW ERRORS ofrece una vista más limpia; y para reaccionar a los diagnósticos desde dentro de un procedimiento, GET DIAGNOSTICS es la herramienta indicada.

Con esto completamos la sección de manejo de errores. Hemos cubierto DECLARE HANDLER, DECLARE CONDITION, SIGNAL, RESIGNAL, SHOW ERRORS y SHOW WARNINGS. En la siguiente sección exploraremos las funciones almacenadas.

Limpieza

Para terminar, eliminamos los procedimientos de ejemplo.

DROP PROCEDURE IF EXISTS operacion_con_warnings;
DROP PROCEDURE IF EXISTS ejemplo_diagnostics;