MySQL Trigger obtiene la consulta actual que provocó el disparo del disparador

El problema aquí es que el alcance de los disparadores de MySQL es a nivel de fila, no a nivel de declaración. Como tal, dentro del disparador tiene acceso a los valores ANTIGUO y NUEVO para cada columna en la fila dada, pero no tiene acceso a la declaración que provocó que se disparara el disparador.

Con respecto a information_schema.processlist, nada se "almacena" (se conserva) en esa vista. Es solo una interfaz SQL para la lista de procesos, y no se puede acceder a la declaración que hizo que se disparara el disparador dentro del alcance del disparador.

Dijiste que no deseas habilitar el registro de consultas general, y este enfoque no es perfecto por varias razones (incluida la granularidad de event_Time de 1 segundo), pero aquí hay un ejemplo de cómo podrías volver a escribir tu disparador usando el tabla de registro general:

SET GLOBAL GENERAL_LOG='ON';
SET GLOBAL LOG_OUTPUT='TABLE';

DELIMITER || 

CREATE TRIGGER DEBUG_DATE BEFORE UPDATE ON db.tbl FOR EACH ROW 
BEGIN 
  DECLARE Q MEDIUMTEXT; 
  SELECT argument INTO Q 
  FROM mysql.general_log 
  where thread_id = connection_id() 
  order by event_time desc 
  limit 1;

  INSERT INTO db.tbl_log (INFO) 
  VALUES (Q); 

END ||

DELIMITER ;