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 errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The active MySQL error-log location is configuration-dependent. Start by asking the running server where it is logging, rather than guessing a path:
SHOW VARIABLES LIKE 'log_error';
SHOW VARIABLES LIKE 'datadir';On Unix-like systems the destination may be the console, a host_name.err file in the data directory, an explicitly configured file such as /var/log/mysqld.log, or a system log. On Windows it is commonly a .err file in the data directory, unless my.ini, --console, --pid-file, or --log-error changes that behavior. MySQL 8.4 can also expose recent events through performance_schema.error_log when the appropriate log sink is enabled.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
What the MySQL error log contains
The error log records when mysqld starts and stops. It also records diagnostic messages generated during startup, normal operation, and shutdown, including errors, warnings, and informational notes. That makes it the first place to look when a server will not start, stops unexpectedly, reports storage problems, refuses a connection because a resource is unavailable, or performs recovery after an unclean shutdown.
An error log is not a record of every SQL statement. MySQL maintains separate logs for different questions:
#1 Best Overall
| Log | What it is for |
|---|---|
| Error log | Problems encountered while starting, running, or stopping mysqld, plus startup, shutdown, warning, and note messages. |
| General query log | A broad record of client connections and queries, used when you need to identify what statements were sent. |
| Slow query log | Queries that meet the configured slow-query criteria. |
| Binary log | Replication and point-in-time-recovery events represented as binary log records. |
| Relay log | Events received by a replication replica. |
| DDL log | Data-definition operations tracked for the relevant server mechanisms. |
Use the error log to understand a server problem; move to another log only when the question requires query history, replication events, or a specific operation record.
Find the active destination from MySQL
Run these statements in a MySQL client account that can inspect server variables:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
SHOW VARIABLES LIKE 'log_error';
SHOW VARIABLES LIKE 'datadir';log_error tells you the configured destination. datadir tells you where to look when the destination is relative to, or derived from, the server’s data directory. Always use the values returned by the running instance: package defaults and local service files can differ between hosts.
How to interpret log_error
| Observed configuration | Where to look | What to do next |
|---|---|---|
No --log-error destination is configured |
On Unix-like systems, the default is the console. | Inspect the service manager, container supervisor, or terminal that launched mysqld instead of searching only for a file. |
--log-error is present without a filename |
MySQL uses host_name.err in the data directory. |
Combine the hostname and the datadir value, then verify the actual filename on disk. |
| An explicit filename is configured | MySQL writes to that file. An absolute path can put it outside the data directory. | Open the exact path returned by the server and check filesystem permissions. |
The destination is stderr |
Messages go to standard error rather than a persistent error-log file. | Read the service manager’s captured output or the host’s system log. |
A package installation may set a conventional path under /var/log, such as /var/log/mysqld.log, but that is a packaging choice, not a universal MySQL rule. The server’s current configuration takes precedence.
Locate and read the log on Linux and other Unix-like systems
1. Confirm the path while the server is running
- Connect with the MySQL client.
- Run
SHOW VARIABLES LIKE 'log_error';and copy the value exactly. - Run
SHOW VARIABLES LIKE 'datadir';so you can resolve a data-directory filename such ashost_name.err. - If the result is a path, verify it from the shell. If it is
stderror the configuration uses the console, inspect the process supervisor instead.
2. Read a file without losing the newest messages
For a file destination, begin at the end because the newest entries are usually closest to the incident:
Rank #2
sudo tail -n 200 /path/from/log_error
sudo less /path/from/log_errorReplace /path/from/log_error with the exact value returned by MySQL. tail gives a quick recent window; less lets you search and move through the full file. If the file is readable only by its owner or by a database-service group, use an account with the necessary filesystem permission rather than changing permissions casually.
To follow a file while reproducing a problem, use:
sudo tail -f /path/from/log_errorStop following with Ctrl+C. Save the relevant lines, including the timestamp immediately before and after the failure, before restarting the server or allowing the file to change.
3. Check systemd output when the destination is the console or stderr
Service names commonly differ by packaging family:
- RPM-based installations commonly use the
mysqldunit. - Debian-based installations commonly use the
mysqlunit.
Check the appropriate unit and then inspect its captured output:
sudo systemctl status mysqld
sudo journalctl -u mysqld --since "1 hour ago"
sudo systemctl status mysql
sudo journalctl -u mysql --since "1 hour ago"Use the commands for the unit that exists on your host. The status view shows whether the service is running and often includes the latest failure. journalctl is useful when MySQL writes to the console or standard error and no standalone file is being created. If the unit forwards messages elsewhere, follow that configured destination instead.
4. Recognize a conventional package path without assuming it
If log_error reports a path such as /var/log/mysqld.log, inspect that file directly:
sudo tail -n 200 /var/log/mysqld.log
sudo less /var/log/mysqld.logDo not substitute this path for the value reported by your server. A distribution, installer, administrator, or custom service file may choose a different filename or redirect output to syslog.
Locate the error log on Windows
Unless --console is used, MySQL for Windows normally writes diagnostic output to a .err file in the data directory. The default basename is based on the host name, while --pid-file can affect the basename. An explicit --log-error option can select another file entirely.
1. Find the configured data directory and options
Open the my.ini used by the Windows service or startup command and check the datadir, log-error, pid-file, and console-related settings. If you can connect to the server, also run:
SHOW VARIABLES LIKE 'log_error';
SHOW VARIABLES LIKE 'datadir';Use the returned path rather than relying on a remembered installer layout. Common MSI installations place data and log files under:
%PROGRAMDATA%MySQLMySQL Server 8.4That location is common, not guaranteed. The active my.ini and service arguments take precedence.
2. Open the .err file
In File Explorer, navigate to the data directory and sort by Date modified. Open the matching .err file with a text editor, or use PowerShell to inspect the newest lines:
Get-Content -Path "C:pathtohost_name.err" -Tail 200Substitute the real path and filename. If MySQL was started with --console, expect diagnostics in the console window instead of a normal file. If --log-error names another path, inspect that path.
3. Check Event Viewer when the Windows Event Log sink is enabled
MySQL can be configured with the log_sink_syseventlog component, which writes to the Windows Event Log. When file output is missing or the service fails before the expected file is created, open Event Viewer and inspect the relevant Windows logs for MySQL entries. This route applies only when that sink is configured; it does not replace checking my.ini and the service command line.
Free tools Windows power users keep installed
One-click scans. No signup required.
Read an incident in the right order
Finding a file is only half the task. Read the entries around the failure systematically.
- Anchor the time. Start with the newest entries and locate the timestamp when the connection failure, restart, crash, or maintenance action occurred.
- Separate lifecycle messages from faults. Startup and shutdown records establish what the server was doing. Warnings and errors explain conditions that may have prevented startup, triggered recovery, or affected runtime behavior.
- Capture identifying details. Copy the timestamp, component or subsystem, numeric error code or symbolic error name, and any path, port, table, plugin, or other object named in the message.
- Classify the immediate cause. Look for messages about filesystem permissions, an unavailable or already-used port, an invalid option, storage-engine recovery, or an unclean shutdown.
- Read the first consequential error before later cascades. A single configuration or permission problem can produce several follow-up warnings. The earliest specific failure is usually the best starting point.
- Correlate with the service state. Compare the log timestamp with
systemctlstatus, Windows service events, or the time a monitoring system reported the outage.
Preserve the surrounding lines rather than copying only one sentence. Context often shows whether a message is a harmless note, a recovery step, or the reason the process exited.
Best Value
Common message patterns and the next check
| Pattern in the message | Next check |
|---|---|
| Permission denied or cannot open a file | Verify the service account’s permissions on the named directory or file, and confirm that the path exists. |
| Address or port unavailable | Check whether another process is using the configured port and whether the MySQL option names the intended address. |
| Unknown or invalid option | Inspect the active option file and startup arguments for spelling, version-specific options, and duplicate settings. |
| Storage-engine recovery or unclean shutdown | Read the complete recovery sequence and verify whether the server reaches a clean “ready” state afterward. |
| Repeated warnings while the server remains online | Determine whether the event is transient, recurring, or tied to a specific client, path, or resource before changing configuration. |
Query recent error events with SQL
MySQL 8.4 can expose recent error-log events through the Performance Schema table performance_schema.error_log when the relevant error-log sink is enabled. This is useful when an administrator has SQL access but not direct access to the database host’s filesystem.
SELECT *
FROM performance_schema.error_log
ORDER BY LOGGED DESC;Granting an account SELECT on this table can provide controlled log access through normal database permissions. The table is a fixed-size in-memory ring buffer: as new events arrive, older events are discarded. Treat it as a recent-events view, not as a permanent archive or a substitute for a retained file, syslog stream, or Windows Event Log.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →When the SQL query returns little or nothing
- The configured sink may not be enabled for the Performance Schema table.
- The event may be older than the table’s retained in-memory window.
- The server may be writing to a file, console, syslog, or Windows Event Log instead.
- Your account may lack
SELECTprivilege on the table.
Use SHOW VARIABLES LIKE 'log_error'; and the host’s service configuration to identify the authoritative destination before concluding that no error was recorded.
Choose between file, service log, and SQL access
More than one view may be available. Select the one that matches the incident and your access constraints:
| Destination or view | Persistence | Access control | Structure | Operational owner |
|---|---|---|---|---|
Text file such as host_name.err or /var/log/mysqld.log |
Stored on disk until rotated, deleted, or otherwise managed by the host. | Filesystem permissions and service-account access. | Traditional text; format follows the configured sink. | Database and host administrators. |
Console or stderr captured by systemd |
Depends on the service manager’s journal retention. | Operating-system and journal permissions. | Service-log records, often searchable by unit and time. | Host or platform operations. |
| Syslog destination | Depends on the syslog facility’s retention and forwarding policy. | Host and centralized-log permissions. | Syslog records or a downstream structured format. | Host or central logging team. |
| Windows Event Log | Depends on Event Viewer log retention and policy. | Windows event-log permissions. | Structured Windows event records. | Windows or platform administrators. |
performance_schema.error_log |
Bounded in-memory ring buffer; older rows are discarded. | SQL privileges, including SELECT. |
Structured table rows. | Database administrators. |
A file or centralized system log is the better source when you need historical evidence. The SQL table is convenient for current events and for environments where filesystem access is intentionally restricted.
What to do when the error log does not explain a crash or hang
The error log is the starting point, not a guarantee that every application-level cause will appear there. If the server remains up but a particular operation fails, inspect the message’s named object and configuration first. If mysqld crashes or hangs without identifying the triggering statement, use the general query log as a separate diagnostic step. MySQL’s troubleshooting documentation describes enabling that log and examining its end for a query that may have caused the failure: MySQL 8.4: Using Log Files.
Do not infer from the absence of a query in the error log that no query was involved. The error log and general query log answer different questions, and enabling additional logging has its own operational and retention implications.
Quick Recap
A repeatable checklist
- Connect to the affected server if possible.
- Run
SHOW VARIABLES LIKE 'log_error';andSHOW VARIABLES LIKE 'datadir';. - Decide whether the destination is a file, console,
stderr, syslog, Windows Event Log, or another configured sink. - On Unix-like systems, inspect the appropriate file or the
mysqld/mysqlsystemd unit. - On Windows, check
my.ini, the data directory, the service arguments, and Event Viewer when the system-event-log sink is configured. - Start with the newest entries surrounding the incident timestamp.
- Record the timestamp, component, error code or symbol, and affected path or object.
- Classify the message as a lifecycle note, warning, configuration problem, permission issue, resource conflict, or storage recovery event.
- If SQL access is easier than host access, query
performance_schema.error_logand remember that it is a bounded in-memory view. - Move to the general, slow-query, binary, relay, or DDL log only when the diagnostic question requires that log.
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.
