MySQL 9.0 版本注意事項
每個錯誤日誌接收器（寫入器）元件都有其用於將訊息寫入目的地的特性輸出格式，但其他因素可能會影響訊息的內容
記錄接收器可用的資訊。如果記錄篩選元件在接收器元件執行之前執行並移除記錄事件欄位，則該欄位不可用於寫入。有關記錄篩選的資訊，請參閱章節 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 錯誤事件優先順序欄位的字串形式。
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 表示 Zulu 時間 (UTC)，或 ±hh:mm（一個偏移量，表示本機系統時區相對於 UTC 的調整值）。例如
2020-08-07T15:02:00.832521Z (UTC)
2020-08-07T10:02:00.832521-05:00 (SYSTEM)