直接给/var/lib/mysql改属主和权限可解决90%初始化失败：执行sudo chown -R mysql:mysql /var/lib/mysql和sudo chmod 750 /var/lib/mysql，确保目录为空、属主为mysql:mysql、权限为drwxr-x---，并清理残留文件如auto.cnf、ib_logfile0等。
直接给 /var/lib/mysql 改属主和权限，90% 的初始化失败就解决了——不是“没用 sudo”，而是 mysqld 进程实际运行时根本进不去那个目录。
查错误日志确认是不是权限问题
执行 sudo mysqld --initialize --user=mysql 失败后，别急着 chmod 777。先看它到底卡在哪：
- 错误里含
Can't create/write to file或OS errno 13 - Permission denied→ 就是权限问题 - 日志末尾出现
Aborting且前面有路径（比如/var/lib/mysql/ibdata1）→ 锁定目标目录 - 用
journalctl -u mysqld -n 50 -o cat看最近 50 行原始输出，比systemctl status更全
重置 /var/lib/mysql 目录的属主与权限
CentOS 7/8 上 MySQL 默认以 mysql 用户和 mysql 组运行，但安装后该目录往往属 root，且权限太松或太严都会被拒。
- 确保目录存在且为空：
sudo rm -rf /var/lib/mysql/*（不删目录本身） - 改属主：
sudo chown -R mysql:mysql /var/lib/mysql - 设权限：
sudo chmod 750 /var/lib/mysql（不能是 777，MySQL 启动会拒绝 world-writable 目录） - 验证：
ls -ld /var/lib/mysql输出第一列应为drwxr-x---，第三、四字段为mysql mysql
检查 secure_file_priv 和 socket 路径是否连带出问题
初始化失败有时不是数据目录本身，而是配置里关联路径权限不对：
-
secure_file_priv如果设成自定义路径（如/data/mysql-files），必须同步赋权：sudo mkdir -p /data/mysql-files && sudo chown mysql:mysql /data/mysql-files && sudo chmod 750 /data/mysql-files -
socket路径（常见于/var/lib/mysql/mysql.sock或/tmp/mysql.sock）的父目录也要可写；若 sock 文件已存在，检查其属主：ls -l /var/lib/mysql/mysql.sock，不是mysql:mysql就删掉再试 -
pid-file路径（如/var/run/mysqld/mysqld.pid）的父目录可能不存在，改成同级路径更稳妥：pid-file = /var/lib/mysql/mysqld.pid，并确保该路径可写
SELinux 干预时的快速绕过与修复
即使权限全对，CentOS 默认开启 SELinux，它可能静默拦截文件创建。现象是日志里没明显报错，但 ausearch -m avc -ts recent 能看到拒绝记录。
- 临时关闭验证：
sudo setenforce 0，再跑初始化；如果成功，就是 SELinux 搞的鬼 - 永久修复不是关 SELinux，而是恢复上下文：
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，然后sudo restorecon -Rv /var/lib/mysql - 别信
chcon临时改上下文——重启后失效，semanage + restorecon才是正解
真正容易被忽略的是：权限修完，残留的 auto.cnf、ib_logfile0 或旧 mysql.sock 文件还在目录里，mysqld 会尝试复用它们，结果因权限不匹配直接退出。清空目录内容比只改权限更可靠。
