There is no single universal MySQL error-log path. The active destination is chosen by the server’s startup options and logging configuration: it may be the console, a host_name.err file in the data directory, an explicitly named file such as /var/log/mysqld.log, a system log, or (in MySQL 8.4) a bounded Performance Schema table. Find the configured destination first, then read the newest entries around the time of the failure.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
What the MySQL error log contains
The error log is the server’s diagnostic record. MySQL’s 8.4 documentation describes it as containing a record of mysqld startup and shutdown times
, plus diagnostic messages such as errors, warnings, and notes produced during startup, shutdown, and normal operation. It is the first place to look when the server will not start, stops unexpectedly, cannot bind its port, cannot open a file, or reports storage-engine recovery.
As an Amazon Associate I earn from qualifying purchases.
The log is not the same thing as a query or replication log. It generally tells you what the server and its components encountered, rather than providing a complete history of every SQL statement.
| Log | What it records | Use it for |
|---|---|---|
| Error log | Startup and shutdown records, runtime warnings, errors, and notes | Startup failures, crashes, permissions, ports, recovery, configuration problems |
| General query log | Connections and SQL statements as they are received | Tracing activity or finding a statement associated with a failure |
| Slow query log | Statements that exceed the configured execution threshold | Performance investigation |
| Binary log | Changes recorded for replication and point-in-time recovery | Replication, recovery, and change history |
| Relay log | Events received by a replication replica | Replica execution and transport problems |
| DDL log | Data-definition operations used by MySQL’s recovery mechanisms | Diagnosing interrupted DDL work |
If you need to prove which SQL statement preceded a crash, that is a separate investigation. MySQL’s log-file troubleshooting guidance explains how to enable the general query log and inspect its end; do not expect the error log alone to contain every query. See MySQL 8.4: Using Log Files.
#1 Best Overall
Find the active destination on Linux and other Unix-like systems
Do not start by guessing a path. Ask the running server which error-log destination it is using, then check whether the value names a file, standard error, or a system logging facility.
1. Query the server configuration
SHOW VARIABLES LIKE 'log_error';
SHOW VARIABLES LIKE 'datadir';Run these statements in a MySQL client with an account allowed to read server variables. log_error identifies the configured destination, while datadir gives you the fallback directory in which a default .err file may reside.
2. Apply MySQL’s destination rules
| Configuration | Result on Unix-like systems |
|---|---|
No --log-error option |
Messages go to the console by default. |
--log-error with no filename |
MySQL uses host_name.err in the data directory. |
--log-error=/path/to/file |
Messages go to that file. An absolute path can place it outside the data directory. |
log_error reports stderr |
Read the service manager’s captured standard error or the host’s system log rather than searching only for a file. |
Distribution packages often set an explicit file under /var/log, such as /var/log/mysqld.log. That is a packaging choice, not a universal MySQL default; the value returned by log_error takes precedence over assumptions based on the operating system.
3. Open the file with the host’s tools
Once log_error returns a path, use the account that owns or is permitted to read that file. For a quick view of the newest records:
sudo tail -n 100 /path/returned/by/log_error
sudo less /path/returned/by/log_errorWith less, press G to jump to the end, then search with / for a timestamp, an error code, ERROR, Warning, or a component name. If the file is rotated, inspect the current file first and then the appropriately dated compressed or archived files managed by your operating system.
4. Follow a systemd service when the destination is not a file
Package conventions commonly name the systemd unit mysqld on RPM-based systems and mysql on Debian-based systems. Use the unit that exists on your host:
sudo systemctl status mysqld
sudo systemctl status mysql
sudo journalctl -u mysqld --since "1 hour ago"
sudo journalctl -u mysql --since "1 hour ago"Do not run both journal commands blindly; select the service name shown by your installation. If the service status says output is being sent to standard error, or log_error is stderr, the journal (or another configured system logger) is the destination. systemctl status also reveals immediate startup failures and the command line used to launch the service, which can expose an unexpected configuration file or --log-error option.
When the server will not start
You may not be able to run SHOW VARIABLES if mysqld never reaches a state in which it accepts connections. In that case, inspect the service definition and startup command, then check the data directory named by the configuration. Look for a recent host_name.err, an explicitly configured log path, or service-manager output. A failed start often leaves the decisive message in the first few lines written during that attempt, so compare the timestamp with the latest start command.
Find the error log on Windows
On Windows, the normal file destination is also configuration-dependent. Unless --console is used, MySQL sends diagnostic output to a .err file in the data directory. The --pid-file option can affect the file’s basename, and an explicit --log-error option can move it elsewhere.
1. Identify the data directory and configuration file
Check the my.ini used by the Windows service, then look for its datadir, log-error, pid-file, and any console setting. Common MSI installations place data and logs below %PROGRAMDATA%MySQLMySQL Server 8.4, or below the installation’s configured data directory. Treat that as a starting point only: local my.ini and service arguments take precedence.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →dir "%PROGRAMDATA%MySQLMySQL Server 8.4"
dir "C:pathtoyourdatadir*.err"If you do not know the service’s configuration, open the Windows Services console, locate the MySQL service, and inspect its executable path and startup arguments. Those arguments can specify a different option file or an explicit log file.
2. Open the newest .err file
Use Notepad, a log viewer, or PowerShell to read the tail of the file:
Get-Content "C:pathtodatadirhostname.err" -Tail 100
Get-Content "C:pathtodatadirhostname.err" -WaitThe first command prints the latest 100 lines; -Wait follows new lines while the server is running. Substitute the actual filename reported by your configuration. If --console was used, there may be no useful file because diagnostics were written to the launching console instead.
3. Check Event Viewer when the Windows event-log sink is configured
MySQL can send errors to the Windows Event Log through its log_sink_syseventlog component. Open Event Viewer and inspect the Windows Logs areas, filtering around the incident time and the MySQL service name. This route is especially important when the expected .err file is absent and the service starts under a managed account with a different filesystem view.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWindows startup failures
The error log is the first resource for a Windows startup failure. Capture the exact timestamp, the first error after the attempted start, and any referenced path. Typical decisive messages identify an unreadable option, a permissions problem in the data directory, a port already in use, or recovery work after an unclean shutdown. Do not infer the path from the product’s installation directory if my.ini specifies another data directory.
Rank #4
Read recent errors through SQL in MySQL 8.4
MySQL 8.4 can expose recent error-log events in the Performance Schema table performance_schema.error_log when the relevant error-log sink is enabled. This is useful when an administrator can grant SQL access but should not grant shell access to log files.
SELECT *
FROM performance_schema.error_log
ORDER BY LOGGED DESC;Start with a limited result set when the table is busy:
SELECT LOGGED, PRIO, ERROR_CODE, SUBSYSTEM, DATA
FROM performance_schema.error_log
ORDER BY LOGGED DESC
LIMIT 100;Column availability and names should be confirmed against the MySQL 8.4 table definition on your server before building tooling around them. Granting SELECT on this table can provide controlled access without exposing the host filesystem.
Understand the retention limit
The table is a fixed-size in-memory ring buffer. As new events arrive, older rows are discarded; it is not a permanent archive and cannot replace file rotation, syslog retention, or centralized collection. If the incident happened hours or days ago, the row may already be gone even though the server is healthy now. Query the table promptly, export the relevant rows, and retain the configured file or system log for historical analysis.
When the table is empty
An empty or unavailable table does not prove that MySQL generated no errors. The required sink may not be enabled, the table may have already overwritten older events, or the account may lack permission. Return to log_error and the host’s configured destination, then verify the server’s error-log components and Performance Schema configuration.
Best Value
How to read an incident chronologically
Reading the newest line in isolation often produces a wrong diagnosis. Use a short, repeatable sequence that preserves context.
- Set the time window. Record when the application observed the failure, when the service was restarted, and the host’s time zone. Open entries a few minutes before and after that window.
- Start at the newest entries. Work backward until you reach the first message associated with the incident, rather than stopping at a later cascade of secondary warnings.
- Separate lifecycle messages. Mark startup and shutdown records separately from runtime warnings and errors. A clean shutdown followed by a successful startup means something different from an abrupt stop followed by storage recovery.
- Capture the identifying fields. Save the timestamp, priority, component or subsystem, numeric error code or symbolic name, full message, and every referenced file, directory, port, table, or plugin.
- Classify the failure. Decide whether the message points to permissions, an unavailable port, an invalid option, a missing file, storage-engine recovery, or an unclean shutdown. Then verify that interpretation against the surrounding entries.
- Check the first cause. Later messages may simply report consequences. For example, a failed option can prevent a plugin from loading, which then produces several follow-on errors. The earliest specific failure is usually the actionable one.
- Correlate with the host. Compare the MySQL timestamp with systemd journal entries, Windows Event Viewer records, deployment logs, disk alerts, and the application error time. A filesystem or process supervisor event can explain why MySQL stopped writing.
- Preserve evidence before changing settings. Copy the relevant lines and the active configuration (with passwords and secrets removed) before restarting repeatedly or rotating files.
Common message patterns
- Permission or ownership errors: identify the exact path and the operating-system account running MySQL. Check access to every parent directory, not only the final file.
- Port unavailable: find which process owns the configured TCP port, then decide whether to stop that process or change the MySQL port consistently for clients and firewall rules.
- Invalid option: locate the option in the active
my.inior Unix option file and confirm spelling, section, and version compatibility before restarting. - Storage-engine recovery: distinguish normal recovery progress from a recovery error. Do not delete data or log files merely to make the message disappear.
- Unclean shutdown: correlate the last clean shutdown with host power loss, process termination, an out-of-memory kill, or a forced service stop.
Compare the available destinations
Choosing where to read the log is an operational decision, not just a path lookup. The same event may be visible in more than one sink, but each has different durability and access controls.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11| Destination | Persistence | Access control | Structure and retention | Operational owner |
|---|---|---|---|---|
| Text file | Persistent until rotation or deletion | Filesystem permissions and service account | Traditional text; retention depends on rotation and storage | Database or host administrator |
Console or stderr |
Depends on the launching process and service manager | Process and service-log permissions | May be ephemeral or captured by journald/Event Viewer | Service manager or platform team |
| Syslog or Windows Event Log | Depends on the host logger’s retention policy | System-log permissions and centralized access rules | Can be centralized and indexed; format depends on the sink | Operating-system or observability team |
performance_schema.error_log |
In-memory only | SQL privileges, such as SELECT |
Structured rows in a fixed-size ring buffer; oldest events are discarded | Database administrator |
If two destinations disagree, first compare their timestamps and retention windows. A file may contain an older event that the SQL ring buffer has already discarded, while a centralized logger may add ingestion delay or normalize fields. Keep one durable destination for incident history and use SQL or the service log for fast, permission-controlled access.
When the error log is not enough
A missing explanation does not mean MySQL produced no useful evidence. It may mean that the relevant information belongs to another log or was emitted before the current destination was configured.
- Use the general query log when you need to identify statements and connections immediately before a failure. Enable it deliberately because it can generate substantial volume and may expose sensitive SQL.
- Use the slow query log for latency and workload problems, not for startup diagnostics.
- Use the binary and relay logs for replication or point-in-time-recovery questions.
- Use the systemd journal, syslog, or Event Viewer when the process was killed, the host rebooted, disk space ran out, or logging was directed to
stderr.
For a crash or hang, preserve the error-log excerpt first, then examine the end of the general query log as a separate diagnostic step. Do not enable every log permanently: choose the smallest additional source that answers the unanswered question, set an explicit retention plan, and disable high-volume logging when the investigation ends.
Quick Recap
A concise checklist
- Query
SHOW VARIABLES LIKE 'log_error';andSHOW VARIABLES LIKE 'datadir';when the server accepts connections. - If the value is a path, read that file and begin at its newest entries.
- If it is
stderror no file exists, inspect the service manager, system log, or Windows Event Viewer. - On Windows, check
my.ini,--console,--pid-file, and--log-errorbefore assuming a default.errname. - In MySQL 8.4, query
performance_schema.error_logonly when its sink is enabled, and remember that the table is a bounded in-memory buffer. - Read around the incident time, identify the earliest specific error, and record its component, code, path, and timestamp.
- Escalate to the general, slow-query, binary, relay, DDL, or host logs only when the error log cannot answer the remaining question.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
