Each error log sink (writer) component has a characteristic output format it uses to write messages to its destination, but other factors may influence the content of the messages:每个错误日志接收器（写入器）组件都有一个特性输出格式，用于将消息写入其目的地，但其他因素可能会影响消息的内容：
The information available to the log sink. If a log filter component executed prior to execution of the sink component removes a log event field, that field is not available for writing. 日志接收器可用的信息。如果在执行接收器组件之前执行的日志筛选器组件删除了日志事件字段，则该字段不可用于写入。For information about log filtering, see Section 5.4.2.4, “Types of Error Log Filtering”.有关日志筛选的信息，请参阅第5.4.2.4节，“错误日志过滤的类型”。
The information relevant to the log sink. Not every sink writes all fields available in error events.与日志接收器相关的信息。并不是每个接收器都会写入错误事件中所有可用的字段。
System variables may affect log sinks. See System Variables That Affect Error Log Format.系统变量可能会影响日志接收器。请参阅影响错误日志格式的系统变量。
For names and descriptions of the fields in error events, see Section 5.4.2.3, “Error Event Fields”. 有关错误事件中字段的名称和描述，请参阅第5.4.2.3节，“错误事件字段”。For all log sinks, the thread ID included in error log messages is that of the thread within mysqld responsible for writing the message. 对于所有日志接收器，错误日志消息中包含的线程ID是mysqld中负责写入消息的线程的ID。This ID indicates which part of the server produced the message, and is consistent with general query log and slow query log messages, which include the connection thread ID.此ID指示服务器的哪个部分生成了消息，并且与包括连接线程ID的常规查询日志和慢速查询日志消息一致。
The internal log sink produces traditional error log output. For example:内部日志接收器生成传统的错误日志输出。例如
2020-08-06T14:25:02.835618Z 0 [Note] [MY-012487] [InnoDB] DDL log recovery : begin 2020-08-06T14:25:02.936146Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/cacert.pem is self signed. 2020-08-06T14:25:02.963127Z 0 [Note] [MY-010253] [Server] IPv6 is available. 2020-08-06T14:25:03.109022Z 5 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 5
Traditional-format messages have these fields:传统格式的消息具有以下字段：
time thread [label] [err_code] [subsystem] msg
The [ and ] square bracket characters are literal characters in the message format. They do not indicate that fields are optional.[和]方括号字符是消息格式中的文字字符。它们并不表示字段是可选的。
The label value corresponds to the string form of the prio error event priority field.label值对应于prio错误事件优先级字段的字符串形式。
The [err_code] and [subsystem] fields were added in MySQL 8.0. [err_code]和[subsystem]字段是在MySQL 8.0中添加的。They are missing from logs generated by older servers. 它们在旧服务器生成的日志中丢失。Log parsers can treat these fields as parts of the message text that is present only for logs written by servers recent enough to include them. 日志解析器可以将这些字段视为消息文本的一部分，该部分仅存在于由足够新的服务器编写的日志中，以包含这些字段。Parsers must treat the 解析程序必须将err_code part of [err_code] indicators as a string value, not a number, because values such as MY-012487 and MY-010051 contain nonnumeric characters.[err_code]指示符的err_code部分视为字符串值，而不是数字，因为MY-012487和MY-010051等值包含非数字字符。
The JSON-format log sink produces messages as JSON objects that contain key-value pairs. For example:JSON格式的日志接收器将消息生成为包含键值对的JSON对象。例如
{
"prio": 3,
"err_code": 10051,
"source_line": 561,
"source_file": "event_scheduler.cc",
"function": "run",
"msg": "Event Scheduler: scheduler thread started with id 5",
"time": "2020-08-06T14:25:03.109022Z",
"ts": 1596724012005,
"thread": 5,
"err_symbol": "ER_SCHEDULER_STARTED",
"SQL_state": "HY000",
"subsystem": "Server",
"buffered": 1596723903109022,
"label": "Note"
}
The message shown is reformatted for readability. Events written to the error log appear one message per line.为便于阅读，显示的消息已重新格式化。写入错误日志的事件每行显示一条消息。
The ts (timestamp) key was added in MySQL 8.0.20 and is unique to the JSON-format log sink. The value is an integer indicating milliseconds since the epoch ('1970-01-01 00:00:00' UTC).ts（时间戳）密钥是在MySQL 8.0.20中添加的，对于JSON格式的日志接收器是唯一的。该值是一个整数，表示自epoch（'1970-01-01 00:00:00'UTC）以来的毫秒数。
The ts and buffered values are Unix timestamp values and can be converted using FROM_UNIXTIME() and an appropriate divisor:ts和buffered的值是Unix时间戳值，可以使用FROM_UNIXTIME()和适当的除数进行转换：
mysql>SET time_zone = '+00:00';mysql>SELECT FROM_UNIXTIME(1596724012005/1000.0);+-------------------------------------+ | FROM_UNIXTIME(1596724012005/1000.0) | +-------------------------------------+ | 2020-08-06 14:26:52.0050 | +-------------------------------------+ mysql>SELECT FROM_UNIXTIME(1596723903109022/1000000.0);+-------------------------------------------+ | FROM_UNIXTIME(1596723903109022/1000000.0) | +-------------------------------------------+ | 2020-08-06 14:25:03.1090 | +-------------------------------------------+
The system log sink produces output that conforms to the system log format used on the local platform.系统日志接收器生成符合本地平台上使用的系统日志格式的输出。
The server generates some error log messages before startup options have been processed, and thus before it knows error log settings such as the 服务器在处理启动选项之前生成一些错误日志消息，因此在知道错误日志设置（如log_error_verbosity and log_timestamps system variable values, and before it knows which log components are to be used. The server handles error log messages that are generated early in the startup process as follows:log_error_verbosity和log_timestamps系统变量值）之前，以及在知道要使用哪些日志组件之前。服务器处理在启动过程早期生成的错误日志消息，如下所示：
Prior to MySQL 8.0.14, the server generates messages with the default timestamp, format, and verbosity level, and buffers them. 在MySQL 8.0.14之前，服务器会生成具有默认时间戳、格式和详细级别的消息，并对其进行缓冲。After the startup options are processed and the error log configuration is known, the server flushes the buffered messages. 在处理完启动选项并知道错误日志配置后，服务器会刷新缓冲的消息。Because these early messages use the default log configuration, they may differ from what is specified by the startup options. 因为这些早期消息使用默认的日志配置，所以它们可能与启动选项指定的不同。Also, the early messages are not flushed to log sinks other than the default. For example, logging to the JSON sink does not include these early messages because they are not in JSON format.此外，早期消息不会刷新到默认值以外的日志接收器。例如，登录到JSON接收器不包括这些早期消息，因为它们不是JSON格式的。
As of MySQL 8.0.14, the server buffers log events rather than formatted log messages. This enables it to retroactively apply configuration settings to those events after the settings are known, with the result that flushed messages use the configured settings, not the defaults. Also, messages are flushed to all configured sinks, not just the default sink.从MySQL 8.0.14开始，服务器缓冲日志事件，而不是格式化的日志消息。这使它能够在设置已知后将配置设置追溯应用于这些事件，结果是刷新的消息使用配置的设置，而不是默认设置。此外，消息会刷新到所有配置的接收器，而不仅仅是默认接收器。
If a fatal error occurs before log configuration is known and the server must exit, the server formats buffered messages using the logging defaults so they are not lost. If no fatal error occurs but startup is excessively slow prior to processing startup options, the server periodically formats and flushes buffered messages using the logging defaults so as not to appear unresponsive. Although this behavior is similar to pre-8.0.14 behavior in that the defaults are used, it is preferable to losing messages when exceptional conditions occur.如果在知道日志配置之前发生了致命错误，并且服务器必须退出，则服务器会使用日志默认值格式化缓冲消息，以免它们丢失。如果没有发生致命错误，但在处理启动选项之前启动速度过慢，则服务器会使用日志记录默认值定期格式化和刷新缓冲消息，以免显得没有响应。尽管此行为与8.0.14之前的行为类似，因为使用了默认值，但当出现异常情况时，最好不要丢失消息。
The log_timestamps system variable controls the time zone of timestamps in messages written to the error log (as well as to general query log and slow query log files). log_timestamps系统变量控制写入错误日志（以及常规查询日志和慢速查询日志文件）的消息中的时间戳的时区。The server applies 服务器在错误事件到达任何日志接收器之前对其应用log_timestamps to error events before they reach any log sink; it thus affects error message output from all sinks.log_timestamp；因此，它会影响所有接收器的错误消息输出。
Permitted 允许的log_timestamps values are UTC (the default) and SYSTEM (the local system time zone). log_timestamps值为UTC（默认值）和SYSTEM（本地系统时区）。Timestamps are written using ISO 8601 / RFC 3339 format: 时间戳是使用ISO 8601/RFC 3339格式编写的：YYYY-MM-DDThh:mm:ss.uuuuuuZ signifying Zulu time (UTC) or ±hh:mm (an offset that indicates the local system time zone adjustment relative to UTC). For example:YYYY-MM-DDThh:MM:ssuuuuu加上表示祖鲁时间（UTC）的尾部值Z或±hh:MM（表示相对于UTC的本地系统时区调整的偏移量）。例如
2020-08-07T15:02:00.832521Z (UTC) 2020-08-07T10:02:00.832521-05:00 (SYSTEM)