Find recent queries in MySQL

Inspect retained Performance Schema statement history or enable a short general-log capture, with correct ordering and logging scope.

Best practices
Illustration of Linux system logging

MySQL can show recent statements only if they were recorded. Start with Performance Schema's retained history. If the evidence is missing, enable a short general-log capture for future traffic; it cannot recover earlier statements retroactively.

Check Performance Schema first

The statement history tables are bounded buffers. Collection depends on enabled instruments and consumers, and events_statements_history_long is not guaranteed to be enabled by default.

SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME LIKE 'events_statements%';

SELECT THREAD_ID, EVENT_ID, SQL_TEXT,
       TIMER_WAIT / 1000000000000 AS seconds
FROM performance_schema.events_statements_history_long
WHERE SQL_TEXT IS NOT NULL
ORDER BY TIMER_START DESC
LIMIT 20;

EVENT_ID is local to a thread, so sorting it across all threads does not produce a global timeline. TIMER_START provides a relative server timer ordering when timing is enabled; it is not a wall-clock timestamp. History contains completed events, may truncate SQL text, and overwrites old entries as its configured capacity fills.

Join THREAD_ID to performance_schema.threads for current connection metadata where available. Entries for connections that have already ended may no longer have a corresponding thread row.

Capture future statements in the general log

Record the existing settings before changing them:

SELECT @@GLOBAL.general_log, @@GLOBAL.log_output;
SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

After reproducing the issue, stop the temporary capture and inspect it:

SET GLOBAL general_log = 'OFF';

SELECT event_time, user_host, command_type, argument
FROM mysql.general_log
ORDER BY event_time DESC
LIMIT 50;

Restore the prior settings if logging was already part of your operations. log_output controls both the general and slow query logs, so changing it has wider effects than this capture alone.

The general log records statements as received and includes connection activity. A recorded statement may fail or never finish; this is different from completed statement history.

Use a file instead

SET GLOBAL log_output = 'FILE';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';
SET GLOBAL general_log = 'ON';

The server must be able to write that path. Follow it with tail -f, then stop the capture and restore prior settings. SQL values can be sensitive even when MySQL rewrites passwords in certain account-management statements.

Use slow logging for a narrower question

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

This captures statements meeting the slow-log conditions instead of all traffic. Optionally enable unindexed-query logging after evaluating its volume; a scan is not necessarily slow.

How do I clear mysql.general_log? Disable the general log first, preserve needed evidence, then use TRUNCATE TABLE mysql.general_log only when removal is intended. The default CSV-backed table is not suited to heavy analytical queries.

How do I see an active query? Use SHOW FULL PROCESSLIST with the appropriate visibility permissions, or inspect current Performance Schema statement events. Completed history and current execution answer different questions.

See Performance Schema statement tables.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting