MySQL权限问题常因文件系统归属、SELinux、systemd沙箱或初始化用户不当引发，需逐层排查：检查/var/lib/mysql等路径归属、SELinux状态、systemd保护设置及mysqld初始化命令与用户匹配。
MySQL 安装时提示 Permission denied 的常见位置
权限不足通常不是全局报错，而是发生在具体操作环节：解压安装包到系统目录、创建数据目录、启动服务进程、写入配置文件或日志文件。关键要看错误信息里带路径的那部分——比如 /var/lib/mysql、/etc/my.cnf、/usr/local/mysql 这些路径是否属于普通用户不可写。
用 sudo 启动 mysqld 却仍失败？检查用户与数据目录归属
即使加了 sudo，如果 mysqld 进程实际以 mysql 用户身份运行（这是默认安全策略），而数据目录 /var/lib/mysql 所属用户不是 mysql，就会被拒绝访问。
实操建议：
- 确认数据目录归属：
ls -ld /var/lib/mysql
，正常应显示
mysql:mysql - 若不匹配，修复命令是：
sudo chown -R mysql:mysql /var/lib/mysql
- 检查 SELinux 是否启用：
getenforce
，若为
Enforcing，临时关闭测试：sudo setenforce 0
（生产环境需配策略而非关闭）
从 tar.gz 包手动安装时，mysql_install_db 报错 Permission denied
该脚本已从 MySQL 5.7.6+ 废弃，改用 mysqld --initialize；但很多教程仍沿用旧命令，导致在非 root 用户下执行时，试图往系统路径写文件而失败。
正确做法：
- 确保以
mysql用户身份初始化：sudo -u mysql mysqld --initialize --datadir=/var/lib/mysql --user=mysql
- 不要用
root用户直接跑初始化——它会生成 root-only 权限的ibdata1等文件，后续mysql用户无法读取 - 若自定义
--basedir，请确认该路径所有者为mysql或至少对mysql用户可读
systemd 服务启动失败，journal 日志里只有 Operation not permitted
这往往不是文件权限问题，而是 systemd 的安全限制触发了。比如启用了 ProtectHome=true 或 NoNewPrivileges=true，而 MySQL 需要访问 /var/lib/mysql（属 ProtectHome 范围）或动态加载插件（受 NoNewPrivileges 限制）。
检查方法：
- 查服务单元配置：
systemctl cat mysqld
- 看是否包含
ProtectHome=yes或NoNewPrivileges=yes - 临时覆盖（仅调试）：
sudo systemctl edit mysqld
，加入：
[Service] ProtectHome=false NoNewPrivileges=false
真正上线前得按最小权限原则重配，比如只放开必要路径：ReadWritePaths=/var/lib/mysql。
最常被忽略的是：MySQL 不只是“装完就能跑”，它的权限模型横跨操作系统用户、文件系统权限、SELinux/AppArmor、systemd 服务沙箱四层。任一层卡住，都会表现为模糊的 Permission denied，必须结合 journalctl -u mysqld -n 50 -f 和 ls -lZ（含 SELinux 上下文）一起看。