答案是权限问题，需确认/var/log/mysql属主为mysql:mysql且权限为755，检查log_error实际生效路径、systemd保护策略及配置文件语法正确性。
Could not use /var/log/mysql 是权限问题，不是路径不存在
这个错误不是说目录没建好，而是 mysqld 进程（运行身份为 mysql 用户）无法在该目录下创建或写入日志文件。即使 /var/log/mysql 存在且有内容，只要属主/权限不对，就会报这个错。
常见现象：
-
error.log路径配置正确（log_error = /var/log/mysql/error.log），但启动后日志为空或根本没生成 - 日志里出现
Failed to open log file '/var/log/mysql/error.log' (Errcode: 13 - Permission denied) -
systemctl start mysql立即失败，journalctl -u mysql显示类似Could not use /var/log/mysql的提示
实操建议：
- 确认目录属主：
ls -ld /var/log/mysql—— 正确应为mysql:mysql，不是root:root或root:syslog - 修复命令：
sudo chown mysql:mysql /var/log/mysql（注意不加-R，只改目录本身） - 权限不能太松：
sudo chmod 755 /var/log/mysql；严禁chmod 777，MySQL 会拒绝启动 - 如果目录不存在，先建再赋权：
sudo mkdir -p /var/log/mysql && sudo chown mysql:mysql /var/log/mysql && sudo chmod 755 /var/log/mysql
log_error 配置项写对了，但 mysqld 还是找不到目录
MySQL 加载 log_error 路径时，只检查父目录是否存在且可写，不校验完整路径是否“合法”。比如你写成 log_error = /var/log/mysql/error.log，但 /var/log/mysql 是符号链接且目标不可写，或者挂载点已满、noexec，也会静默失败。
排查要点：
- 用
readlink -f /var/log/mysql确认是否软链，再检查真实路径的属主和权限 - 检查磁盘空间：
df -h /var/log，mysqld启动时若发现父目录所在分区满（100%），会放弃写日志并退出 - 检查挂载选项：
mount | grep "$(df /var/log | tail -1 | awk '{print $1}')" | grep -E "(noexec|nosuid)"，含noexec通常不影响日志，但nosuid+ 特殊 SELinux 策略可能干扰 - 临时绕过配置测试：
sudo -u mysql touch /var/log/mysql/test.log 2>/dev/null && echo ok || echo fail，直接模拟写入行为
systemctl 启动失败，但手动运行 mysqld 却能写日志
这说明 systemd 上下文限制了 mysqld 的能力，最常见的是 ProtectSystem=full 或 ReadOnlyDirectories=/var/log 这类加固配置挡住了日志写入。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
验证与处理：
- 查 unit 文件限制：
systemctl cat mysql.service | grep -E "(Protect|ReadOnly|Restrict)" - 典型冲突项：
ProtectSystem=strict会把/var/log设为只读；ReadWriteDirectories=/var/log/mysql可显式放行（加在[Service]段） - 不要直接删 ProtectSystem —— 安全策略有其用途；优先改日志路径到允许写的区域，比如数据目录：
log_error = /var/lib/mysql/error.log - 改完记得重载：
sudo systemctl daemon-reload
日志目录权限修好了，还是报 Could not use
这时问题大概率不在目录本身，而在 MySQL 启动流程更早的阶段：配置加载失败导致 log_error 根本没生效，进程退回到默认日志路径（通常是数据目录下的 hostname.err），而你还在盯着 /var/log/mysql 白忙活。
关键动作：
- 先别管
log_error，用mysqld --verbose --help | grep "log-error"看 “Resolved” 行输出的实际路径——这才是它真正在用的位置 - 检查
my.cnf语法：sudo mysqld --defaults-file=/etc/my.cnf --validate-config（5.7+），报错就说明配置解析中断，log_error压根没读到 - 确认
[mysqld]段落位置正确，段落外不能有未注释的配置项（如裸写port=3306），否则整段跳过 - 如果用
include引入其他 conf，检查被 include 的文件是否存在、可读、无语法错
真正卡住的地方，往往是你以为已经搞定了的配置文件。
