Por defecto en MySQL, lo normal es solo tener el log de errores activado, sin embargo, es habitual tener la necesidad de activar un registro un poco más amplio para todas las consultas en una base de datos o sistema de software, puede ser algo necesario ante ciertos problemas, ya sea por razones de auditoría como de solución de problemas.

En primer lugar, un registro log de consultas SQL pueden ser una opción valiosa para realizar un seguimiento de todas las consultas que ocurren en el sistema, sobre todo en tiempos de ORM que abstraen toda la complejidad de una base de datos reduciendo a unas líneas de código y prescindiendo de SQL y no sabemos muy bien que ocurre por debajo.

Por eso mismo, nos podemos encontrar con problemas en una aplicación y el origen de los mismos, no está en nuestro código, sino que se origina en la compatibilidad y en como como el ORM traduce el código a las consultas SQL por debajo, activando un registro podemos verificar su compatibilidad con el motor de base de datos y ver que la falla no sea por ese lado.

Consideraciones

Mantener siempre activo un registro de consultas o logs de queries en una base de datos, puede tener diversas desventajas, principalmente que pueden afectar negativamente el rendimiento, la estabilidad y la seguridad de un sistema, por lo que debe habilitarse solo en entornos de desarrollo o solo como último recurso y por breves periodos de tiempo en producción.

En primer lugar, los logs de queries pueden consumir una cantidad significativa de espacio de almacenamiento, especialmente en sistemas con un alto volumen de consultas, todo esto puede llevar a un aumento en los costos de almacenamiento y a la necesidad de recursos adicionales para gestionar y mantener estos registros, lo que puede ser innecesario si no se están utilizando para un propósito específico.

Además, mantener registros de consultas puede plantear preocupaciones de seguridad,  los logs de queries pueden contener información sensible, como nombres de usuario, contraseñas y datos confidenciales de los usuarios, si no se protegen adecuadamente, estos registros podrían ser vulnerables a ataques de seguridad y filtraciones de datos, lo que podría tener graves consecuencias para la privacidad de los usuarios y la reputación de una empresa.

Otro aspecto a considerar es el rendimiento del sistema, los logs de queries pueden ralentizar el rendimiento de una base de datos o sistema, ya que cada consulta debe ser registrada antes de ser ejecutada, en sistemas con un alto tráfico de consultas, esto puede traducirse en una perdida de rendimiento que afecta negativamente la experiencia del usuario.

En resumen, mantener activo un registro de consultas debe hacerse con precaución y con un propósito claro, ya que puede tener implicaciones en términos de almacenamiento, seguridad y rendimiento, que deben ser cuidadosamente evaluadas antes de su implementación.

Activar el log para todas las consultas

Hasta MySQL 5.6

Para activar el log en versiones antiguas, hasta la versión 5.6 debemos directamente desde la consola MySQL ejecutando lo siguiente:

SET global log_output = 'FILE';
SET global general_log_file='/var/log/querys.log';
SET global general_log = 1;

El valor log_output establece la salida del registro para el servidor MySQL, en este caso en un archivo (‘FILE’), esto significa que los registros generados por el servidor, incluidas las consultas SQL, se guardarán en un archivo en lugar de mostrarse en la salida estándar o en la consola del servidor.

También admite valores como TABLE y NONE, en caso de TABLE redirige los registros a una tabla específica en la base de datos,  se puede definir una tabla en la que se almacenen los registros generados por el servidor, esto puede ser útil si deseas mantener los registros de manera estructurada en la base de datos para un análisis posterior o para retención a largo plazo.

En el caso de NONE, desactiva completamente la generación de registros. Si estableces log_output en ‘NONE‘, el servidor MySQL no registrará ningún tipo de registro, lo que puede ser útil en situaciones donde no se requiere ningún registro y se busca minimizar el impacto en el rendimiento y el uso de recursos del servidor.

En la opcion general_log_file se especifica la ubicación y el nombre del archivo de registro para el registro general de consultas, en este caso, las consultas se registrarán en un archivo llamado “querys.log” ubicado en el directorio “/var/log”, todas las consultas SQL ejecutadas en el servidor serán registradas en este archivo.

Por último en general_log se habilita (o no) el registro de consultas al establecer el valor de general_log en 1 (o “ON”). Una vez que esta configuración está activada, el servidor comenzará a registrar todas las consultas SQL ejecutadas en el archivo especificado en general_log_file.

A continuación veremos como se habilita dependiendo de la versión de MySQL, hay dos caminios, el correcto dependera si es anterior a MySQL 5.6 o posterior.

MySQL 5.6 en adelante

Para versiones posteriores a la 5.6 debemos hacerlo directamente desde el archivo de configuración my.cnf y agregando:

[mysqld]
general_log = on
general_log_file=/var/log/querys.log

La explicación de ambos valores es igual a la anterior, en este caso debemos reiniciar la base de datos systemctl restart mysql o systemctl restart mysqld, o con service es sistemas más antiguos.

Para ambos

Luego debemos crear el archivo en disco y darle los permisos adecuados:

touch /var/log/querys.log
chown mysql:mysql /var/log/querys.log

Activar el log para detectar solo las consultas lentas.

Para el caso que estemos intentando detectar las consultas más lentas y problemáticas, podemos habilitar las consultas únicamente para este tipo

long_query_time=3
slow_query_log=1
slow_query_log_file=/var/log/slow.log

long_query_time: Es la configuración que determina el umbral de tiempo en segundos que una consulta debe superar para considerarse una “consulta lenta” y ser registrada en el registro de consultas lentas, este valor se utiliza para identificar consultas que pueden estar afectando negativamente el rendimiento del servidor y que requieren atención para su optimización.

slow_query_log: Esta configuración habilita o deshabilita el registro de consultas lentas, cuando slow_query_log está configurado en 1 (o “ON”), significa que el registro de consultas lentas está activado y las consultas que cumplan con el umbral de tiempo definido en long_query_time serán registradas en el archivo de registro de consultas lentas.

slow_query_log_file Esta configuración especifica la ubicación y el nombre del archivo de registro de consultas lentas, al igual que en el caso anterior, conviene crear y asignar permiso manualmente:

 
touch /var/log/slow.log 
chown mysql:mysql /var/log/slow.log 

Por supuesto, se requiere reiniciar la base de datos systemctl restart mysql o systemctl restart mysqld, o con service es sistemas más antiguos.

Conclusión

En conclusión, la activación de registros o logs de consultas en una base de datos o sistema de software es una práctica que debe abordarse con precaución y con un propósito claro, por defecto, lo común es mantener activado únicamente el registro de errores, ya que activar registros más amplios para todas las consultas puede tener desventajas significativas en términos de rendimiento, seguridad y recursos de almacenamiento.

Sin embargo, existen situaciones en las que la activación de registros de consultas más amplios se vuelve necesaria, estos registros pueden ser valiosos para auditorías, solución de problemas y seguimiento de la actividad del sistema, aunque nunca hay que tenerlos activos más que lo estrictamente necesario.