MySQL 8.0+ 默认启用错误日志，但实际是否写入文件取决于启动方式：mysqld_safe 写入 hostname.err，systemd 管理时可能交由 journald，此时 log_error 为 NULL；log_error 不可动态修改，需在配置文件中设置绝对路径并确保权限正确；MySQL 无传统日志级别，log_error_verbosity 控制消息类型（1= 仅错误，2= 错误 + 警告，3= 默认含常规信息）；log_error_services 决定日志输出链路，默认为内部写入，若设为 log_sink_null 则日志消失。
MySQL 错误日志是否默认开启？
MySQL 8.0+ 默认启用错误日志，但具体行为取决于启动方式和配置。如果使用 mysqld_safe 启动，错误日志通常写入 hostname.err（位于 datadir 下）；若用 systemd 管理且未显式配置，日志可能被重定向到 journald，此时 mysqld 进程本身不生成传统文件日志。
- 检查是否实际写入文件：运行
SHOW VARIABLES LIKE 'log_error';，返回值为NULL表示未启用文件日志（常见于 systemd + journald 场景） - 确认日志输出位置：
SELECT @@log_error;或查看mysqld --verbose --help | grep "log-error" - 若返回空或
/dev/null，说明错误日志被禁用或转交系统日志服务
如何手动启用并指定错误日志路径？
必须在 MySQL 配置文件 （如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）的 [mysqld] 段中设置 log_error，重启生效。不能通过 SET GLOBAL 动态修改。
[mysqld] log_error = /var/log/mysql/error.log # 注意：目录需存在，且 mysqld 进程有写权限 # 若路径含目录，确保父目录由 mysql 用户可写（chown mysql:mysql /var/log/mysql）- 路径必须是绝对路径；相对路径会被忽略或导致启动失败
- MySQL 不会自动创建缺失的父目录，
mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql必须提前执行 - 修改后需
systemctl restart mysql（或service mysql restart），仅 reload 不生效
MySQL 有“日志级别”吗？error_log_level 是什么？
MySQL ** 没有 ** 类似 Log4j 的 TRACE/DEBUG/INFO/WARN/ERROR 分级机制。所谓“错误日志级别”实为误解——它只记录严重性事件（启动、关闭、断言失败、崩溃、连接异常、权限拒绝等），不提供粒度控制。
-
log_error_verbosity（MySQL 5.7.2+）才是关键参数，控制“哪些类型的消息写入错误日志” - 取值范围：1（仅错误）、2（错误 + 警告）、3（错误 + 警告 + 普通信息，如启动完成、SSL 加载）
- 默认值为 3，生产环境建议设为 2，避免日志被常规信息刷屏
- 该变量支持动态修改：
SET GLOBAL log_error_verbosity = 2;，但重启后失效，需同步写入配置文件
常见错误现象与排查要点
日志没内容、日志写入失败、日志内容远少于预期，多数源于权限、路径或服务管理逻辑问题。
- 启动失败且无日志：检查
log_error路径的父目录权限，确认mysql用户能否在该路径下touch test.txt - 日志文件存在但大小为 0：可能是
log_error值被覆盖（例如配置文件中多个[mysqld]段，后加载的覆盖前一个） - 日志里只有“Starting MySQL”就停止：检查
mysqld是否真的崩溃退出，用systemctl status mysql查看最近状态及 journald 输出 - 升级 MySQL 后日志消失：新版本可能改用
log_error_suppression_list屏蔽部分消息，或默认启用log_error_services（MySQL 8.0.13+）接管日志输出链路
最易被忽略的是 log_error_services —— 它决定日志“怎么写”，默认值 "log_filter_internal; log_sink_internal" 表示走内部过滤 + 内部写入；若被误设为 "log_sink_null"，日志就彻底消失了。
