The error log contains information indicating when mysqld was started and stopped and also any critical errors that occur while the server is running. If mysqld notices a table that needs to be automatically checked or repaired, it writes a message to the error log.
On some operating systems, the error log contains a stack trace if mysqld dies. The trace can be used to determine where mysqld died. See MySQL Internals: Porting to Other Systems.
In the following discussion, “console” means
stderr, the standard error output; this is your
terminal or console window unless the standard error output has
been redirected.
On Windows, the --log-error and
--console options both affect error
logging:
Without --log-error,
mysqld writes error messages to
in the data directory.
host_name.err
With
--log-error[=,
mysqld writes error messages to an error
log file. The server uses the named file if present, creating
it in in the data directory unless an absolute path name is
given to specify a different directory. If no file is named,
the default name is
file_name]
in the data directory.
host_name.err
If --console is given,
mysqld writes error messages to the
console, unless --log-error is
also given. If both options are present, the last one takes
precedence.
In addition, on Windows, events and error messages are written to
the Windows Event Log within the Application log. Entries marked
as Warning and Note are
written to the Event Log, but not informational messages such as
information statements from individual storage engines. These log
entries have a source of MySQL. You cannot
disable writing information to the Windows Event Log.
On Unix and Unix-like systems, mysqld writes error log messages as follows:
Without --log-error,
mysqld writes error messages to the
console.
With
--log-error[=,
mysqld writes error messages to an error
log file. The server uses the named file if present, creating
it in the data directory unless an absolute path name is given
to specify a different directory. If no file is named, the
default name is
file_name]
in the data directory.
host_name.err
At runtime, log_error system
variable indicates the the error log file name if error output is
written to a file.
If you flush the logs using
FLUSH LOGS or
mysqladmin flush-logs and
mysqld is writing the error log to a file (for
example, if it was started with the
--log-error option), it renames the
current log file with the suffix -old, then
creates a new empty log file. Be aware that a second log-flushing
operation thus causes the original error log file to be lost
unless you save it under a different name. For example, you can
use the following commands to save the file:
shell>mysqladmin flush-logsshell>mvhost_name.err-oldbackup-directory
No error log renaming occurs when the logs are flushed if the server is not writing to a named file.
If you use mysqld_safe to start
mysqld, mysqld_safe arranges
for mysqld to write error messages to a log
file. If you specify a file name using
--log-error to
mysqld_safe or mysqld, that
file name is used. Otherwise, mysqld_safe uses
the default error log file.
If mysqld_safe is used to start
mysqld and mysqld dies
unexpectedly, mysqld_safe notices that it needs
to restart mysqld and writes a
restarted mysqld message to the error log.
The --log-warnings option or
log_warnings system variable can
be used to control warning logging to the error log. The default
value is enabled (1). Warning logging can be disabled using a
value of 0. If the value is greater than 1, aborted connections
are written to the error log. See
Section C.5.2.11, “Communication Errors and Aborted Connections”.

User Comments
I did some testing with MySQL 4.0.21 this morning. Here's a typical snippet from my "hostname.err" file. To generate this, I did a "NET START MySQL", connected with one session and ran a 2000-entry query, and then did a "NET STOP MySQL" while the query was still returning data.
MySql: ready for connections.
Version: '4.0.21-nt-log' socket: '' port: 3306 Source distribution
040923 10:00:00 MySql: Normal shutdown
040923 10:00:01 MySql: Forcing close of thread 1 user: 'root'
040923 10:00:01 InnoDB: Starting shutdown...
040923 10:00:03 InnoDB: Shutdown completed
040923 10:00:03 MySql: Shutdown Complete
The Windows Application Event Log recorded 3 messages at the same time. All of the messages corresponded with the entries prefixed with the "MySQL:" entries in the hostname.err file. (OK)
However, all 3 messages were logged as ERRORS; this designation is misleading. If anything, the "Normal Shutdown" and "Shutdown Complete" messages should have been logged as INFORMATION and the "Forcing close of thread..." message should have been logged as a WARNING.
Also, it is important to note that the MySQL service startup was NOT LOGGED in the Event Log.
Long story short, if you are a Windows user, it is probably still best (as of 4.0.21) to stick with your existing "parse-the-.err" script rather than rely on the Windows Event Log if you're interested in MySQL service starts, stops and abnormal events.
Add your own comment.