错误日志为空几乎一定是log_error未配置、路径错误或MySQL进程无写权限；必须用绝对路径显式配置，确保目录存在、属主为mysql:mysql、权限正确（755）、SELinux/AppArmor放行，且磁盘空间充足。
错误日志为空，几乎一定是 log_error 没配、配错路径、或 MySQL 进程没权限写入。 它不会报错，也不会自动创建目录，而是彻底静默跳过——连空文件都不会生成。
log_error 没配置或用了相对路径
MySQL 8.0 不再默认启用错误日志；如果 my.cnf 的 [mysqld] 段里没写 log_error，它可能退回到写到数据目录下的 hostname.err，但这个路径常被忽略，且权限大概率不对。
- 运行
mysql -Nse "SELECT @@log_error;"，如果返回空或NULL，说明根本没生效 -
log_error必须是绝对路径，比如/var/log/mysql/error.log，不能是logs/error.log或./error.log - 路径中所有父目录（如
/var/log/mysql/）都必须存在，且 MySQL 进程用户（通常是mysql）有执行（x）权限
路径存在但 MySQL 没写权限
即使你手动 touch /var/log/mysql/error.log 成功，MySQL 启动后文件仍为空，大概率是属主或权限问题。MySQL 会拒绝写入非属主目录，也不会提示。
- 执行
ls -ld /var/log/mysql，确认输出里是mysql:mysql，不是root:root或其他用户 - 正确赋权：
sudo chown -R mysql:mysql /var/log/mysql，然后sudo chmod 755 /var/log/mysql - 千万别用
chmod 777—— MySQL 会直接拒绝启动
SELinux 或 AppArmor 拦截了写入
在 CentOS/RHEL（SELinux）或 Ubuntu（AppArmor）上，即使路径和权限全对，安全策略也可能禁止 mysqld 写入非标准日志路径。现象是服务“看似启动成功”，但日志始终为空。
- 临时测试：CentOS/RHEL 上运行
sudo setenforce 0，Ubuntu 上运行sudo systemctl stop apparmor - 如果此时日志开始生成，说明策略是真凶；需为
log_error路径添加对应策略规则，而不是永久关闭 - 不要跳过这步 —— 很多运维在权限检查无误后就放弃，其实卡在这里
Windows 下的 .err 文件藏得深
Windows 默认不走 log_error 配置，而是把错误日志写进 datadir 目录下的 主机名.err（如 LAPTOP-ABC123.err），而这个目录默认是隐藏的 C:\ProgramData\MySQL\MySQL Server 8.0\Data\。
- 在文件资源管理器中启用“显示隐藏的项目”，才能看到
ProgramData - 若
datadir被改过（比如指向C:\mysql8\data），那日志就在那个目录下，不是ProgramData - 如果该
.err文件也为空，说明 MySQL 根本没走到日志模块初始化阶段 —— 此时要立刻怀疑datadir权限、路径拼写或磁盘挂载问题
最容易被忽略的是：日志为空 ≠ MySQL 没出错，而是它连日志系统都没来得及加载。一旦发现 log_error 路径下什么都没有，别先查 SQL，先确认 MySQL 进程是否真的获得了对那个路径的写能力 —— 包括路径存在、属主正确、SELinux/AppArmor 放行、Windows 下隐藏目录可见。
