MySQL 5.7+ 默认启用错误日志，路径依安装方式而定：Linux 多为 /var/log/mysqld.log 或 /var/log/mysql/error.log，Windows 在 data/ 目录下；需通过 mysqld --verbose --help 查默认路径，并注意权限、SELinux 及配置冲突。
错误日志默认是否开启？
MySQL 5.7+ 默认启用错误日志，但具体路径和行为取决于安装方式与配置。使用 mysqld --verbose --help 可查默认日志路径；若未显式配置 log_error，Linux 下通常落于 /var/log/mysqld.log 或 /var/log/mysql/error.log，Windows 下多在 MySQL 安装目录的 data/ 子目录中，文件名类似 HOSTNAME.err。
关键判断依据是启动时是否报错：Could not open error log file 或 Can't start server: can't read log error —— 这说明日志路径不可写或配置冲突。
如何手动指定并验证 log_error 配置？
修改 my.cnf（Linux）或 my.ini（Windows）的 [mysqld] 段：
log_error = /var/log/mysql/error.log
注意以下几点：
-
/var/log/mysql/目录必须存在，且 MySQL 进程用户（如mysql）有写权限，否则服务无法启动 - 路径不能是符号链接（某些版本会拒绝写入）
- 不建议用相对路径，如
./error.log，它基于datadir解析，易混淆 - 修改后需重启 MySQL：运行
systemctl restart mysqld（RHEL/CentOS）或sudo service mysql restart（Ubuntu/Debian）
验证是否生效：mysql -e "SHOW VARIABLES LIKE 'log_error';"，输出值应与配置一致；再用 tail -f /var/log/mysql/error.log 观察是否有新条目（如启动完成提示、警告等）。
错误日志里哪些内容对故障排查最关键？
不是所有日志都值得细看。重点关注以下几类行：
- 以
ERROR开头的行：如ERROR 1045 (28000): Access denied for user，直接指向权限或认证失败 - 包含
Aborting或mysqld: Shutdown complete的上下文：常伴随崩溃前的堆栈或信号（如signal 11），提示内存或插件问题 -
InnoDB: Database page corruption类提示：说明数据页损坏，需检查磁盘或恢复备份 - 反复出现的
Table 'xxx' doesn't exist或Unknown table engine 'InnoDB'：可能因配置错乱（如禁用了引擎）或 frm 文件丢失
注意：日志默认不记录 SQL 语句本身（那是通用查询日志或慢日志的事），错误日志只记录服务层异常，不反映业务逻辑错误。
常见配置陷阱与兼容性差异
不同版本 MySQL 对错误日志行为有细微差别：
- MySQL 5.6 不支持
log_error_verbosity，而 5.7+ 默认为 3（记录 warning/error/info），设为 1 会大幅减少日志量，但也可能漏掉关键线索 - Percona Server 和 MariaDB 支持
log_warnings = 2增强连接拒绝详情，但官方 MySQL 8.0 已弃用该参数，改用log_error_verbosity = 3 - 若启用了
syslog（通过log_error_services = log_filter_internal;log_sink_sysevent），错误可能不落地到文件，而发往系统日志 —— 此时要查journalctl -u mysqld而非文件 - Docker 环境下，
log_error若指向容器内路径（如/var/log/mysql/），需确保 volume 映射正确，否则日志随容器销毁而丢失
最易被忽略的是权限和 SELinux：CentOS/RHEL 上即使目录属主正确，SELinux 上下文不对（如 unconfined_u:object_r:var_log_t:s0 缺失）也会导致写入失败，此时需 restorecon -Rv /var/log/mysql。
