Introduction

MySQL can write several kinds of logs, and the first step in viewing them is knowing which log you actually need. Error, general query, slow query, and binary logs answer different operational questions, so finding the right file or server setting matters more than memorizing one file path.

Know Which Log You Want

The most common MySQL logs are:

• the error log for server startup, shutdown, and runtime problems
• the general query log for every client statement
• the slow query log for expensive queries
• the binary log for data-change replication history

If the question is "why did MySQL fail to start," look at the error log. If the question is "which query is slowing the system down," the slow query log is the better place to start.

Check the Current Log Configuration

MySQL can expose the active log locations through variables. Start there instead of guessing paths.

1SHOW VARIABLES LIKE 'log_error';
2SHOW VARIABLES LIKE 'general_log%';
3SHOW VARIABLES LIKE 'slow_query_log%';
4SHOW VARIABLES LIKE 'log_output';

This tells you whether a given log is enabled and, for file-based logs, where MySQL is configured to write it.

If log_output is set to TABLE, then some logs may be stored in MySQL system tables instead of plain files.

View the Error Log From the Shell

On systems where the error log is file-based, standard shell tools are often the fastest way to inspect it.

tail -n 100 /var/log/mysql/error.log

or follow it live:

tail -f /var/log/mysql/error.log

The exact path varies by operating system and packaging, which is why checking SHOW VARIABLES or the MySQL configuration file is better than assuming one location.

Enable and Inspect the General Query Log Carefully

The general query log records all statements and can be useful for short-term debugging, but it can create a lot of noise and overhead.

SET GLOBAL general_log = 'ON';
SHOW VARIABLES LIKE 'general_log_file';

Then inspect the file at the reported path, or query the table form if log_output uses tables.

SELECT * FROM mysql.general_log ORDER BY event_time DESC LIMIT 20;

Do not leave the general log enabled casually on a busy production system unless you have a clear reason.

Use the Slow Query Log for Performance Work

For query tuning, the slow query log is usually much more useful than the general query log because it focuses on problematic statements.

SET GLOBAL slow_query_log = 'ON';
SHOW VARIABLES LIKE 'slow_query_log_file';
SHOW VARIABLES LIKE 'long_query_time';

Once enabled, inspect the file directly or use tools that summarize it. The slow query log is often where real performance work starts, because it narrows the surface area to the queries worth investigating.

Binary Logs Are Different

Binary logs are not human-readable query logs. They are replication-oriented change logs and are usually inspected with mysqlbinlog.

mysqlbinlog /var/lib/mysql/binlog.000001 | head -n 50

Use binary logs when you care about replication, point-in-time recovery, or auditing data changes. Do not expect them to behave like the general or slow query logs.

Common Pitfalls

The most common mistake is looking at the wrong log type for the problem. Another is assuming all logs are enabled by default and file-based on every installation.

Developers also often enable the general query log in production and forget that it can produce a lot of output and overhead.

Finally, do not guess the log path from blog posts or old server habits. Check the active MySQL variables or configuration so you are reading the actual current destination.

Summary

• MySQL uses different logs for errors, query tracing, slow queries, and replication history.
• Start by checking server variables to see which logs are enabled and where they are written.
• Use shell tools for file-based error and query logs.
• Use the slow query log for performance investigation rather than turning on general logging by default.
• Use mysqlbinlog for binary logs, because they serve a different purpose from text query logs.