MySQL 8.4 发行说明
每个错误日志接收器（写入器）组件都有一个用于将其消息写入目的地的特征输出格式，但其他因素可能会影响消息的内容
日志接收器可用的信息。如果在执行接收器组件之前执行的日志过滤器组件删除了日志事件字段，则该字段不可用于写入。有关日志过滤的信息，请参见第 7.4.2.4 节，“错误日志过滤类型”。
与日志接收器相关的信息。并非每个接收器都写入错误事件中可用的所有字段。
系统变量可能会影响日志接收器。参见影响错误日志格式的系统变量。
有关错误事件中字段的名称和描述，请参见第 7.4.2.3 节，“错误事件字段”。对于所有日志接收器，错误日志消息中包含的线程 ID 是mysqld中负责写入消息的线程的线程 ID。此 ID 指示服务器的哪个部分生成了消息，并且与通用查询日志和慢查询日志消息一致，这些消息包含连接线程 ID。
内部日志接收器生成传统的错误日志输出。例如
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传统格式的消息具有以下字段
time thread [label] [err_code] [subsystem] msg[ 和 ] 方括号字符是消息格式中的字面字符。它们并不表示字段是可选的。
label 值对应于 prio 错误事件优先级字段的字符串形式。
[err_code] 和 [subsystem] 字段是在 MySQL 8.0 中添加的，因此在旧服务器生成的日志中不存在。日志解析器可以将这些字段视为仅存在于最近的服务器（包含这些字段）写入的日志中的消息文本的一部分。解析器必须将 err_code 部分视为字符串值，而不是数字，因为 MY-012487 和 MY-010051 等值包含非数字字符。
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"
}显示的消息已重新格式化为易于阅读。写入错误日志的事件每行显示一条消息。
ts（时间戳）键是 JSON 格式的日志接收器独有的。该值是一个整数，表示自纪元（'1970-01-01 00:00:00' UTC）以来的毫秒数。
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 |
+-------------------------------------------+服务器在启动选项被处理之前（因此在它知道错误日志设置，例如 log_error_verbosity 和 log_timestamps 系统变量值，以及在它知道要使用哪些日志组件之前）生成一些错误日志消息。服务器处理在启动过程中早期生成的错误日志消息的方式如下
服务器缓冲日志事件（而不是格式化的日志消息），这使得它能够在设置已知后追溯地将配置设置应用于这些事件，从而导致刷新的消息使用配置的设置，而不是默认值。此外，消息被刷新到所有配置的接收器，而不仅仅是默认接收器。
如果在日志配置已知之前发生致命错误，并且服务器必须退出，服务器将使用日志默认值格式化缓冲的消息，以防止它们丢失。如果未发生致命错误，但启动在处理启动选项之前过慢，服务器将定期使用日志默认值格式化和刷新缓冲的消息，以避免出现无响应。尽管此行为使用默认值，但它优于在发生异常情况时丢失消息。
系统变量 log_timestamps 控制写入错误日志（以及常规查询日志和慢查询日志文件）的消息中的时间戳的时间区域。服务器在错误事件到达任何日志接收器之前应用 log_timestamps；因此，它影响来自所有接收器的错误消息输出。
允许的 log_timestamps 值为 UTC（默认值）和 SYSTEM（本地系统时区）。时间戳使用 ISO 8601 / RFC 3339 格式写入：YYYY-MM-DDThh:mm:ss.uuuuuuZ 表示祖鲁时间（UTC）或 ±hh:mm（表示本地系统时区调整相对于 UTC 的偏移量）的尾部值。例如
2020-08-07T15:02:00.832521Z (UTC)
2020-08-07T10:02:00.832521-05:00 (SYSTEM)