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] 指示器中的 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 格式日誌接收器獨有的。該值是一個整數，指示自 epoch ('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)