MySQL启动失败报“Permission denied”需先查journalctl日志定位路径，再分情况处理：目录属主错误、systemd保护机制、SELinux/AppArmor拦截；用户权限问题则要区分USER()与CURRENT_USER()、检查GRANTS及bind-address等。
MySQL启动失败报“Permission denied”怎么定位？
这不是数据库用户权限问题，而是操作系统层面的文件访问权限或安全模块拦截。关键看错误日志里具体哪条路径被拒绝——journalctl -u mysql -n 50 --no-pager 是第一手线索。
- 如果日志出现
Failed to create /var/run/mysqld/mysqld.sock：说明/var/run/mysqld目录不存在，或属主不是mysql，运行sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld - 如果报
Can't open the mysql.plugin table或卡在初始化阶段：大概率是数据目录/var/lib/mysql属主不对，执行sudo chown -R mysql:mysql /var/lib/mysql（切勿跳过-R） - 若日志含
Operation not permitted：很可能是 systemd 的ProtectHome=true或ProtectSystem=full在起作用，临时验证可sudo systemctl edit mysql加入ProtectHome=false，但生产环境应改用允许路径（如 socket 放/run/mysqld/）
用户能登录但执行 SELECT/CREATE 报错“Access denied”怎么办？
登录成功 ≠ 权限到位。MySQL 区分 USER()（你用什么连）和 CURRENT_USER()（实际匹配到哪个授权账户），两者不一致就容易误判。
- 先确认当前上下文：
SELECT USER(), CURRENT_USER();—— 如果返回'app@192.168.1.100'和'app@%'，说明 host 匹配正常；若后者是''@'localhost'，说明有匿名用户干扰，得删掉：DROP USER ''@'localhost'; - 查真实权限：
SHOW GRANTS FOR 'app'@'%';，注意输出里是否真有SELECT ON mydb.*，而不是只有USAGE - 远程连接时，务必检查
my.cnf中bind-address = 0.0.0.0（不是127.0.0.1），且防火墙放行端口，否则即使权限全开也连不上
mysqldump 备份失败提示“Access denied”常见原因
备份不是只靠 SELECT 权限就够的，MySQL 要求显式授予多个元数据权限，否则会静默失败或报错。
- 必须权限至少包括：
SELECT（读数据）、SHOW VIEW（导出视图定义）、TRIGGER（导出触发器）、LOCK TABLES（加锁保障一致性） - 授权命令示例：
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON mydb.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES; - 如果备份目标路径（如
/backup/）是 root 创建的，普通用户无写权限，mysqldump会直接报错退出——此时要检查ls -ld /backup，而非只盯 MySQL 权限
SELinux 或 AppArmor 拦截导致“权限不足”的特征与修复
这类问题最隐蔽：文件属主、权限全对，systemd 配置也没错，但就是启动失败。典型表现是日志里没明确路径报错，只有一句 Permission denied，且 setenforce 0 后立刻正常。
- SELinux 环境下，先运行
sestatus确认是否为enforcing；临时关闭测试：sudo setenforce 0；若恢复启动，则需修复上下文：sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，再sudo restorecon -Rv /var/lib/mysql - Ubuntu/Debian 上更可能是 AppArmor 拦截，运行
sudo aa-status | grep mysql查看是否加载了配置；临时禁用：sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/usr.sbin.mysqld && sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld - 切记：不要长期关闭 SELinux/AppArmor，它们拦住的往往是真实风险，比如 mysqld 意外读取了
/etc/shadow
MySQL 权限问题真正难的不是操作步骤，而是区分「系统权限」和「数据库权限」这两层——前者决定 mysqld 进程能不能活下来，后者决定用户能不能干活。很多人卡在中间，既改了 GRANT 又调了 chown，却忘了看一眼 aa-status 或 sestatus。
