log_error必须置于[mysqld]段落，使用绝对路径并确保mysql用户有写权限，重启后用SHOW VARIABLES验证，MySQL 8.0+需配置log_error_services禁用JSON格式。
log_error 参数必须写在 [mysqld] 段落里
MySQL 的 log_error 是 mysqld 进程专属配置，只在 [mysqld] 块中生效。如果错写在 [client] 或 [mysql] 下，重启后完全无效，且不会报错——日志照旧输出到默认路径（如 /var/log/mysqld.log 或 /var/lib/mysql/hostname.err）。
实操建议：
- 用
grep -A 5 -B 5 "log_error" /etc/my.cnf确认它是否在[mysqld]下方 - 若文件含多个
[mysqld]（比如有[mysqld1]），注意匹配正确的段落 - 路径必须是 mysqld 进程用户（通常是
mysql）有写权限的目录，否则启动失败，错误提示为：Can't open error log file: Permission denied
路径写法要区分绝对路径和相对路径
log_error 的值如果是相对路径（例如 log_error = mysql_error.log），MySQL 会把它拼接到 datadir 路径下，不是当前工作目录，也不是 my.cnf 所在目录。这常导致日志“消失”——你以为写到了 /etc/，其实被创建在 /var/lib/mysql/mysql_error.log。
实操建议：
- 一律使用绝对路径，比如
log_error = /var/log/mysql/error.log - 提前建好目录并授权：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 不要依赖默认行为；
log_error = ./error.log和log_error = error.log效果一致，都算相对路径
修改后必须重启 mysqld，且需验证是否真正生效
改完 my.cnf 不重启，配置不加载；重启后也不代表一定成功——常见失败原因是权限、路径不存在或 SELinux 限制（尤其 CentOS/RHEL）。
实操建议：
- 重启命令用
sudo systemctl restart mysqld（或mysql，取决于服务名） - 检查进程是否起来：
systemctl status mysqld，留意 “failed” 或 “exited” - 确认实际加载的配置：
mysql -e "SHOW VARIABLES LIKE 'log_error';"，返回值必须是你设的绝对路径 - 手动触发一个错误（如
DROP TABLE nonexistent;），再查对应日志文件是否有新内容
MySQL 8.0+ 的 error log 默认是 JSON 格式，影响排查体验
MySQL 8.0.22 起，默认 log_error 输出为 JSON 格式（log_error_services = 'log_filter_internal;log_sink_json'），人类可读性差，grep 和 tail -f 都不方便。
实操建议：
- 如需传统文本日志，在
[mysqld]中显式覆盖：log_error_services = 'log_filter_internal;log_sink_syseventlog;log_sink_json'→ 改为log_error_services = 'log_filter_internal;log_sink_syseventlog' - 或者更干脆：只留文本输出：
log_error_services = 'log_filter_internal;log_sink_syseventlog'（去掉log_sink_json） - 该参数修改后同样需重启；不改的话，
log_error路径仍有效，只是内容是 JSON 行
MySQL 错误日志路径看似只改一行，但真正起效依赖段落位置、路径权限、服务重启、格式兼容四重校验。漏掉任意一环，都会让你在 /var/log/ 下翻半天却找不到刚触发的错误。
