错误日志默认是否开启？
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。
