How to Resolve "MySQL Slow Query Log Not Recording Queries"

You've enabled MySQL's slow query log expecting to catch problematic queries, but the log file stays empty even though you know slow queries are happening. This is almost always a configuration mismatch — the log isn't actually enabled the way you think, is writing somewhere unexpected, or the threshold is set too high to catch anything.

The Problem

You set up the slow query log, run a query you know is slow, and nothing shows up:

$ tail -f /var/log/mysql/mysql-slow.log
(nothing appears, even after running an intentionally slow query)

Checking whether the feature is even active reveals it might not be:

mysql> SHOW VARIABLES LIKE 'slow_query_log';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| slow_query_log | OFF   |
+----------------+-------+

Why It Happens

The slow query log has several independent settings that all need to be correct simultaneously, and missing any one of them results in an empty log with no error to point you at the problem. Common causes:

• The feature is simply disabled — slow_query_log defaults to OFF on most MySQL installs, and enabling it requires an explicit setting change.
• The threshold is too high — long_query_time defaults to 10 seconds, meaning genuinely slow queries in the 1-9 second range never get logged at all unless you lower it.
• Output destination mismatch — log_output can be set to TABLE (writing to mysql.slow_log) instead of FILE, so you're checking the wrong place entirely if you're tailing a log file while output is configured to go to a table.
• The setting was changed with SET GLOBAL only, which doesn't persist across a restart — a subsequent MySQL restart silently reverts to whatever's in my.cnf.
• File permission issues preventing MySQL from writing to the configured log file path at all.

The Fix

Check every relevant setting together:

SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_output';

+---------------------+----------------------------+
| Variable_name       | Value                      |
+---------------------+----------------------------+
| slow_query_log      | OFF                        |
| slow_query_log_file | /var/log/mysql/slow.log    |
| long_query_time     | 10.000000                  |
| log_output          | FILE                       |
+---------------------+----------------------------+

Enable it and lower the threshold to something that will actually catch what you're looking for:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Make the change persistent so it survives a restart, by also setting it in my.cnf:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_output = FILE

If log_output is set to TABLE instead of FILE, query the table directly rather than looking at a file at all:

SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;

Confirm MySQL can actually write to the configured log file path:

ls -la /var/log/mysql/slow.log

-rw-r----- 1 mysql mysql 0 Aug  7 10:00 /var/log/mysql/slow.log

If the file doesn't exist or has the wrong owner, MySQL may be silently failing to write to it — create it with correct ownership:

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

Restart MySQL and test with a deliberately slow query:

SELECT SLEEP(2);
tail -f /var/log/mysql/slow.log

Still Not Working?

If the log is enabled, the threshold is low, and permissions are correct, but administrative queries and replication traffic aren't showing up when you expect them to, check whether log_slow_admin_statements and log_queries_not_using_indexes are set the way you actually want — by default, certain query categories are excluded from the slow log even when the feature itself is fully working:

SET GLOBAL log_slow_admin_statements = 'ON';
SET GLOBAL log_queries_not_using_indexes = 'ON';

The second setting specifically logs any query that doesn't use an index at all, regardless of how fast it happens to run on a small table — useful for catching queries that will become slow later as the table grows, well before they show up under the normal time-based threshold.