MySQL无法写入日志主因是操作系统层权限或路径问题，需依次检查日志路径是否存在、目录归属与权限（mysql用户读写）、SELinux策略拦截及手动验证写入能力。
MySQL 无法写入日志文件，多数情况是权限或路径配置问题，核心要检查 日志目录归属、用户权限、SELinux（Linux）及配置路径是否真实存在。
确认 MySQL 日志路径是否正确且目录存在
先查 MySQL 实际使用的日志路径：
- 登录 MySQL 执行：
SHOW VARIABLES LIKE '%log%';，重点关注general_log_file、slow_query_log_file、log_error - 检查返回的路径（如
/var/log/mysql/error.log）是否真实存在；若目录不存在（如/var/log/mysql/），需手动创建 - 确保路径中**每一级父目录都已存在**，MySQL 不会自动创建多级目录
检查日志目录归属与权限
MySQL 进程以特定系统用户运行（通常是 mysql），该用户必须对日志文件及其所在目录有读写权限：
- 运行
ps aux | grep mysql查看主进程用户（如mysql） - 执行
ls -ld /var/log/mysql，确认目录属主为mysql:mysql；不是则修复：sudo chown -R mysql:mysql /var/log/mysql - 目录权限建议为
750或755，日志文件权限通常由 MySQL 自动设为640，无需手动改
检查 SELinux 是否拦截（仅限 CentOS/RHEL/Fedora）
SELinux 可能阻止 MySQL 写入非标准路径（如自定义日志目录）：
- 运行
sestatus确认是否启用；若为enforcing，临时设为 permissive 测试：sudo setenforce 0 - 若问题消失，说明 SELinux 是原因；永久放行需打标签：
sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"，再执行sudo restorecon -Rv /var/log/mysql - 不建议直接关闭 SELinux，应通过策略适配
验证 MySQL 用户能否手动写入测试文件
用 MySQL 运行用户直接测试写权限，避免误判：
- 切换用户：
sudo -u mysql touch /var/log/mysql/test_write.log - 若报错
Permission denied，说明权限或 SELinux 仍有问题；成功则说明文件系统层无阻碍 - 记得清理测试文件：
sudo -u mysql rm /var/log/mysql/test_write.log
不复杂但容易忽略。重点不在 MySQL 配置本身，而在于它背后的操作系统权限上下文。定位清楚是哪一层卡住，问题就解决了一大半。
