MySQL 5.0 Reference Manual  /  ...  /  The General Query Log

5.2.2 The General Query Log

The general query log is a general record of what mysqld is doing. The server writes information to this log when clients connect or disconnect, and it logs each SQL statement received from clients. The general query log can be very useful when you suspect an error in a client and want to know exactly what the client sent to mysqld.

mysqld writes statements to the query log in the order that it receives them, which might differ from the order in which they are executed. This logging order is in contrast with that of the binary log, for which statements are written after they are executed but before any locks are released. (Also, the query log contains all statements, whereas the binary log does not contain statements that only select data.)

To enable the general query log, start mysqld with the --log[=file_name] or -l [file_name] option.

If the general query log file is enabled but no name is specified, the default name is host_name.log and the server creates the file in the same directory where it creates the PID file. If a name is given, the server creates the file in the data directory unless an absolute path name is given to specify a different directory.

Server restarts and log flushing do not cause a new general query log file to be generated (although flushing closes and reopens it). On Unix, to rename the file and create a new one, use the following commands:

shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory

On Windows, you cannot rename a log file while the server has it open before MySQL 5.0.17. You must stop the server, rename the file, and then restart the server to create a new log file. As of 5.0.17, this applies only to the error log. However, a stop and restart can be avoided by using FLUSH LOGS, which causes the server to rename the error log with an -old suffix and open a new error log.

The general query log should be protected because logged statements might contain passwords. See Section, “Passwords and Logging”.

Download this Manual
User Comments
  Posted by Jason Bibbings on January 14, 2011
On Windows, I could not get the Log Files to work using the default path of "C:/Program Files (x86)/MySQL/MySQL Server 5.1"

This was on Windows Server 2008 using 32-bit MySQL version 5.1.49

Moving the logs out of that directory and into the root C: fixed the issue for me. All I can figure is the logs don't like the parentheses in (x86), I've seen this a couple times before.

Anyway if it helps anyone, my current working my.ini file on Windows now looks like this:

# Set Slow Query Log
long_query_time = 1
slow_query_log = 1
slow_query_log_file = "C:/slowquery.log"

#Set General Log
log = "C:/genquery.log"

  Posted by Greg Schretter on November 16, 2011
Correct most system do not like "()" also the "." might cause issues, but it might be a good idea to have the files written some where else besides root. Maybe C:\MySql\Logs\(different sub-directory names base on category). Root should be locked down on Windows servers. Hope this helps..

  Posted by Jakob Langgaard on April 21, 2012
The reason why the log file won't work in "C:/Program Files (x86)/MySQL/MySQL Server 5.1" is because programs need to be run with administrator privileges to be able to write or modify files within the program files folder.
  Posted by Programmer Old on April 3, 2013
Find "datadir" in "my.ini": for me the line is
datadir="C:/ProgramData/MySQL/MySQL Server 5.5/Data/"

Likly that something along this path is what you want
  Posted by Sebastian Kaiser on September 9, 2015
Example: Cleanup log:
I am logging into my database itself... but after 1 day, there will be about 180k queries of log. ( in a file, it would be 30MB per day <.<)
This script is an example to keep the table clean ;) even if you forgot it for a week or 2 you can cleanup even then ;)
You need to add an additional column (event_unix) and then you can use this script to keep the log clean... it will update the timestamp into a Unix-timestamp, delete the logs older than 1 day and then (i don't know why, but in my log, the event_time is setted into the actual time) update the event_time into Timestamp from event_unix... sounds a bit confusing, but it's working great :D Would use it as an event, but the event is disallowe the change from general_log...

Commands for the new column:
SET GLOBAL general_log = 'OFF';
RENAME TABLE general_log TO general_log_temp;
ALTER TABLE `general_log_temp`
ADD COLUMN `event_unix` int(10) NOT NULL AFTER `event_time`;
RENAME TABLE general_log_temp TO general_log;
SET GLOBAL general_log = 'ON';

cleanup script =>

SET GLOBAL general_log = 'OFF';
RENAME TABLE general_log TO general_log_temp;
UPDATE general_log_temp SET event_unix = UNIX_TIMESTAMP(event_time);
DELETE FROM `general_log_temp` WHERE `event_unix` < UNIX_TIMESTAMP(NOW()) - 86400;
UPDATE general_log_temp SET event_time = FROM_UNIXTIME(event_unix);
RENAME TABLE general_log_temp TO general_log;
SET GLOBAL general_log = 'ON';

Hope you like it ;)

Regards, S.K.
Sign Up Login You must be logged in to post a comment.