log_error参数必须在[mysqld]段配置绝对路径，确保mysql用户对目录有写权限，修改后需重启服务并用show variables验证；selinux/apparmor策略可能拦截写入，需针对性处理。
log_error 参数决定了 MySQL 错误日志写到哪，改它就能换位置 —— 但光改配置不够，目录权限和重启缺一不可。
怎么改 log_error 配置项
编辑 MySQL 主配置文件（通常是 /etc/my.cnf 或 /etc/mysql/my.cnf），在 [mysqld] 段落下添加或修改这一行：
log_error = /var/log/mysql/mysqld.log
注意：log_error 是唯一控制错误日志路径的变量，log-error（带连字符）是旧版本兼容写法，新版本推荐用下划线形式；MySQL 启动时只认 [mysqld] 下的设置，[mysqld_safe] 里的 log-error 在较新版本中已不生效。
目录必须存在且 MySQL 用户可写
MySQL 进程以 mysql 用户身份运行，目标路径的父目录必须由该用户拥有写权限。常见错误现象是服务启动失败，日志里反复出现 OS error number 13 或 Permission denied。
- 先创建目录：
sudo mkdir -p /var/log/mysql - 再赋权：
sudo chown mysql:mysql /var/log/mysql - 别漏掉父级目录（如
/var/log）的执行权限，否则mysql用户无法进入子目录
改完必须重启 mysqld 才生效
log_error 不支持运行时动态修改，SET GLOBAL 对它无效。改完配置后必须重启服务：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
sudo systemctl restart mysql
验证是否生效：
mysql -e "SHOW VARIABLES LIKE 'log_error';"
输出的 Value 字段应与你配置的路径一致；同时检查该路径下是否生成了新日志文件（旧日志不会自动迁移，需手动清理）。
SELinux 或 AppArmor 可能拦截写入
即使权限看着没问题，CentOS/RHEL 上 SELinux、Ubuntu 上 AppArmor 也可能阻止 MySQL 写入非默认路径。典型表现：服务启动卡住、无错误日志、journalctl -u mysql 显示 AVC denied。
- 临时排查：运行
sudo setenforce 0（SELinux）或sudo aa-disable /usr/sbin/mysqld（AppArmor），再试重启 - 长期方案：为新路径打 SELinux 标签，例如
sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"，然后sudo restorecon -Rv /var/log/mysql
权限和策略问题最容易被跳过，但恰恰是改路径失败的主因 —— 尤其当错误日志本身都写不出来时，得靠 journalctl -u mysql 或 strace -p $(pgrep mysqld) 才能定位真实拦路虎。
