Introduction

SHOW PROCESSLIST is a quick way to see what MySQL threads are doing right now, but the plain form truncates the SQL text in the Info column. If you are debugging a long query, lock wait, or runaway ORM statement, the fix is usually to switch to the full view and, when needed, query richer metadata tables.

Use SHOW FULL PROCESSLIST

The most direct answer is to add the FULL keyword:

SHOW FULL PROCESSLIST;

Without FULL, the Info column is shortened. With FULL, MySQL returns the complete statement text for active threads that you are allowed to see.

That is enough for many day-to-day debugging tasks such as:

• identifying a blocking query
• confirming the exact SQL an application is running
• spotting a query stuck in a poor execution path

Filter the Output with SQL

When the server is busy, raw process-list output gets noisy fast. Querying the process list table lets you filter it like normal SQL:

1SELECT
2    ID,
3    USER,
4    HOST,
5    DB,
6    COMMAND,
7    TIME,
8    STATE,
9    INFO
10FROM INFORMATION_SCHEMA.PROCESSLIST
11WHERE COMMAND <> 'Sleep'
12ORDER BY TIME DESC;

This is especially useful when you want to focus on long-running active work instead of hundreds of sleeping connections.

You can narrow it even further:

1SELECT ID, TIME, STATE, INFO
2FROM INFORMATION_SCHEMA.PROCESSLIST
3WHERE INFO IS NOT NULL
4  AND TIME >= 5
5ORDER BY TIME DESC;

That gives you long-running queries with actual SQL text attached.

Permissions Matter

If you only see your own sessions, the issue may not be the command at all. In MySQL, broad visibility into other users' threads typically requires the PROCESS privilege. Without that privilege, your output can look incomplete even when you are using SHOW FULL PROCESSLIST correctly.

So when someone says "it still does not show the full query," check two things first:

• are they using FULL
• do they have permission to see the target thread

For More Than the Current Moment

SHOW FULL PROCESSLIST is a snapshot of what is active now. It is not query history. If the statement already finished, process list output will not help.

For deeper investigation, MySQL's performance schema is often the better tool. For example, you can inspect currently executing statements there as well:

1SELECT
2    THREAD_ID,
3    EVENT_NAME,
4    SQL_TEXT,
5    TIMER_WAIT
6FROM performance_schema.events_statements_current
7WHERE SQL_TEXT IS NOT NULL;

That becomes valuable when you need richer instrumentation than process list alone provides.

Practical Troubleshooting Flow

A simple workflow works well in production:

1. start with SHOW FULL PROCESSLIST
2. if the server is noisy, query INFORMATION_SCHEMA.PROCESSLIST
3. if you need statement instrumentation or recent history, move to performance schema
4. if a query is blocking others, combine the SQL text with lock and transaction inspection

That keeps the tools matched to the question instead of overcomplicating every incident.

Common Pitfalls

• Using SHOW PROCESSLIST and expecting full SQL text without the FULL keyword.
• Forgetting that finished queries no longer appear there.
• Assuming missing rows mean there is no activity when the real issue is lack of PROCESS privilege.
• Looking only at the Info column without checking Time and State, which often provide the real clue.
• Treating process list as history instead of as a snapshot of current threads.

Summary

• Use SHOW FULL PROCESSLIST to see the full SQL text of active queries.
• Query INFORMATION_SCHEMA.PROCESSLIST when you need filtering or ordering.
• Check privileges if you cannot see other sessions.
• Use performance schema when you need richer current-statement or historical insight.
• Process list is a live snapshot, not a query-history system.