log_error配置必须为绝对路径且mysql进程有写权限，须置于[mysqld]段下，路径需存在并属主正确，linux需配合logrotate的create和usr1信号，windows需避免反斜杠转义错误。
log_error 配置项必须是绝对路径，且 MySQL 进程有写权限
MySQL 启动时会尝试往 log_error 指定的文件写入启动日志和后续错误；如果路径不存在、是相对路径、或 MySQL 用户（如 mysql）没权限写入，它会静默失败——既不报错，也不记录，连 mysqld --help --verbose 里显示的默认值都可能“假有效”。
- 绝对路径是硬性要求：
/var/log/mysql/error.log✅，./error.log或error.log❌ - 确认目录存在且属主属组正确：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql - 配置文件中写死路径，别依赖环境变量或符号链接（MySQL 不解析它们）
my.cnf 里 log_error 必须放在 [mysqld] 段下，不能放错位置
log_error 是服务端选项，只在 [mysqld] 或 [server] 段生效；放在 [client]、[mysqld_safe] 或全局段开头，MySQL 会直接忽略，还可能让你误以为配置成功了。
- 正确位置示例：
[mysqld] log_error = /var/log/mysql/error.log
- 检查是否生效：连接后执行
SELECT @@log_error;，返回值应与配置一致 - 如果返回空或
stderr，说明配置未加载——优先检查段落位置和配置文件是否被真正读取（可用mysqld --print-defaults验证）
Linux 下 error log 文件可能被 logrotate 清空，但 MySQL 不自动 reopen
logrotate 默认用 copytruncate 或直接 mv + touch，导致 MySQL 进程还在往旧 inode 写，新文件始终为空。现象是：磁盘上文件大小为 0，但 lsof -i :3306 | grep log 显示进程仍持有一个已删除的文件句柄。
- 解决方法一（推荐）：logrotate 配置中加
create 640 mysql mysql和postrotate … kill -USR1 `cat /var/run/mysqld/mysqld.pid` … endscript，触发 MySQL 重开日志 - 解决方法二：不用 logrotate，改用 MySQL 原生轮转（需开启
log_error_services = "log_filter_internal; log_sink_file"并配log_error_suppression_list等，5.7+ 才支持） - 临时验证：手动
sudo kill -USR1 $(cat /var/run/mysqld/mysqld.pid)，看新日志是否开始写入
Windows 上 log_error 路径反斜杠要双写或用正斜杠
Windows 配置文件（my.ini）里如果写 log_error = C:mysqllogserror.log，MySQL 会把 l 当作换行符处理，实际路径变成乱码，最终写入失败或写到奇怪位置。
- 安全写法一（推荐）：
log_error = C:/mysql/logs/error.log - 安全写法二：
log_error = C:\mysql\logs\error.log - 务必确认 MySQL 服务以哪个用户运行（常是 SYSTEM），该用户需对目标目录有写权限（右键目录 → 属性 → 安全 → 编辑 → 添加 SYSTEM → 允许写入）
log_error 返回空值时，90% 是配置没进 [mysqld] 段，或路径权限卡住了。
