必须改配置文件并重启，log_error和log_error_verbosity均不可动态生效；90%以上失败源于段落错、权限缺、SELinux拦截；log_error须置于[mysqld]段且为绝对路径，目录需提前创建并赋权mysql:mysql，log_error_verbosity=3可临时增强排障信息但需及时回调。
必须改配置文件并重启，log_error 和 log_error_verbosity 都不能靠 SET GLOBAL 动态生效（部分版本甚至会报错）；路径写错段落、权限没给够、SELinux 拦截，这三类问题占线上配置失败的 90% 以上。
log_error 必须放在 [mysqld] 段里，且只能是绝对路径
写在 [client] 或 [mysql] 下完全被忽略，MySQL 启动也不报错，日志照旧写进 @@datadir 下的 hostname.err，你根本意识不到配置失效。
- 用
grep -n "\[mysqld\]" /etc/my.cnf定位段落起始行，确保log_error = /var/log/mysql/error.log紧跟其后 - 路径不能是
log_error = error.log或log_error = ./error.log—— MySQL 会把它拼到数据目录下，不是你想要的位置 - 目录必须提前创建：
sudo mkdir -p /var/log/mysql，再赋权：sudo chown mysql:mysql /var/log/mysql - Docker 场景下，宿主机挂载目录需匹配容器内
mysql用户 UID（官方镜像通常是 999），否则写入失败
log_error_verbosity 控制写什么，不是“日志级别”而是消息类型开关
MySQL 没有 INFO/WARN/ERROR 分级，log_error_verbosity 只决定是否记录 [Note] 类消息。默认值 2（错误 + 警告）在主从中断、权限拒绝等场景下信息不足，临时调到 3 才能看到线程 ID、插件名、SQL 上下文。
- 配置文件中加一行：
log_error_verbosity = 3（必须在[mysqld]段下） - 运行时可尝试
SET GLOBAL log_error_verbosity = 3，但 MySQL 8.0.22+ 已移除该变量的动态支持，执行会报Variable 'log_error_verbosity' is a read only variable - 设为 3 后日志量明显增大，排查完务必改回 2，避免刷屏和磁盘膨胀
- 云数据库（如阿里云 RDS）通常禁用该变量的动态修改，只能改配置并重启
验证是否真生效，别只看变量值
执行 SHOW VARIABLES LIKE 'log_error' 返回路径，不代表日志就写进去了——权限不对、SELinux 拦截、路径不存在都会导致静默回退到默认位置。
- 检查实际日志文件：
sudo -u mysql tail -n 1 /var/log/mysql/error.log，应能看到类似mysqld: ready for connections的启动信息 - 对比旧路径：
ls -l /var/lib/mysql/*.err，如果还在更新，说明配置根本没加载 - SELinux 场景下，
sudo ausearch -m avc -ts recent | grep mysqld可查拦截记录；临时关闭测试：sudo setenforce 0 - AppArmor（Ubuntu）需检查：
sudo dmesg | grep -i avc | grep mysqld
最容易被跳过的一步：改完配置后，不验证日志内容是否按预期输出。很多故障现场的日志“看似存在”，实则全是旧内容或空文件——因为 log_error 配置无效，而 log_error_verbosity 设了等于没设。
