log_error_verbosity 是 MySQL 控制错误日志详细级别的参数，值为1/2/3分别记录 ERROR、WARNING（默认）、NOTE 及调试上下文；生产环境默认值2常不足以定位权限拒绝、主从中断等隐性故障，需临时调至3获取线程ID、插件名等关键线索，但不可长期启用。
log_error_verbosity 是什么，为什么不能只靠默认值
log_error_verbosity 控制 MySQL 错误日志里写什么内容：1 只记 [ERROR]，2 加上 [Warning]（默认），3 还包含 [Note] 和部分调试上下文。生产环境用默认值 2 往往不够——比如权限拒绝、主从同步中断、InnoDB 表空间加载失败，这些在 2 级下可能只显示为一行警告，但把级别提到 3 后，你会看到更完整的上下文（如具体 SQL 线程 ID、触发的插件、甚至堆栈线索），这对快速定位“服务没挂但查询莫名失败”类问题很关键。
- MySQL 5.7.2+ 才支持该参数，5.6 及更早版本无效
- 级别 3 日志量明显增大，不建议长期开启；临时排障后应调回 2
- 某些云数据库（如阿里云 RDS）禁用动态修改，必须改配置文件并重启
怎么改：配置文件 vs 动态 SET，哪个更可靠
两种方式都能生效，但适用场景不同。配置文件修改是永久性的，适合初始化或上线前固化策略；SET GLOBAL log_error_verbosity = 3 是运行时生效，不用重启，适合紧急排查。
- 配置文件路径常见于：
/etc/my.cnf、/etc/mysql/my.cnf或 Docker 容器内/etc/mysql/conf.d/my.cnf - 必须加在
[mysqld]段下，单独写log_error_verbosity = 3即可，无需引号 - 动态设置需有
SUPER权限，且部分 MySQL 8.0.22+ 版本已移除对该变量的动态支持（执行会报错Variable 'log_error_verbosity' is a read only variable） - 改完配置文件后必须重启 MySQL，否则不生效；
systemctl restart mysql或mysqld_safe --defaults-file=... &
日志路径和权限经常被忽略，导致“设了等于没设”
只改 log_error_verbosity 不够，还得确保 log_error 指向的位置 MySQL 进程真能写进去。常见错误是路径不存在、目录属主不对、SELinux 或 AppArmor 拦截。
- 先确认路径存在且可写：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 在配置文件中明确指定：
log_error = /var/log/mysql/error.log（不要留空，也不要依赖默认的hostname.err） - Docker 场景下，必须把宿主机日志目录挂载进容器，并确保容器内
mysql用户 UID 匹配（官方镜像通常 UID=999） - 改完后检查是否真正落盘：
sudo -u mysql touch /var/log/mysql/test.log 2>/dev/null || echo "权限不对"
验证是否生效：别只看变量值，要看日志里有没有对应内容
执行 SHOW VARIABLES LIKE 'log_error_verbosity' 只说明变量读出来是 3，不代表日志真按这个级别写了。最直接的办法是触发一条 [Note] 级别的事件，再查日志。
- 手动触发一个 Note：执行
FLUSH LOGS（它会在日志里写入[Note] ... Rotating...） - 然后立刻查日志：
tail -n 20 /var/log/mysql/error.log | grep "\[Note\]" - 如果没输出，说明要么日志路径不对，要么 MySQL 没读到新配置（检查 error log 开头是否有 “unknown variable” 报错）
- 注意：
log_warnings参数（旧版用）已被弃用，设了也不影响log_error_verbosity，别混用
