MySQL启动报“Permission denied”应先通过journalctl定位被拒绝的具体路径，再递归修正属主（如sudo chown -R mysql:mysql /var/lib/mysql），并检查父目录权限、SELinux/AppArmor拦截及socket目录（/var/run/mysqld）是否就绪。
MySQL启动报“Permission denied”先看日志里拒绝的是哪个路径
直接执行 journalctl -u mysql -n 50 --no-pager，重点找类似 Can't create test file /data/var/.lower-test 或 Could not open file './err.log': Permission denied 这样的行。错误路径决定了你要修哪里——不是所有“Permission denied”都该改 /var/lib/mysql。
chown必须递归且对准mysql用户，不能只改目录不改子项
常见错误是只运行 chown mysql:mysql /var/lib/mysql，但没加 -R。MySQL初始化或启动时会访问子目录（如 mysql/、performance_schema/）和文件（如 ibdata1、err.log），这些若仍属 root，就会报错。
- 正确做法：先确认数据目录位置，比如
datadir = /var/lib/mysql，然后执行sudo chown -R mysql:mysql /var/lib/mysql - 顺手检查
/var/run/mysqld（socket 目录）：若不存在就建，再sudo mkdir -p /var/run/mysqld && sudo chown mysql:mysql /var/run/mysqld - 别漏掉升级目录（如
/var/lib/mysql-upgrade），它也得是mysql:mysql
chown之后还报错？可能是SELinux或AppArmor在拦
即使 ls -l 显示属主正确、权限是755，strace 或 audit.log 仍可能暴露 SELinux 拒绝操作。典型现象是手动跑 mysqld --defaults-file=/etc/my.cnf 能启，但 systemctl start mysql 就失败。
- 临时验证：执行
sudo setenforce 0（仅限测试），再试启动；若成功，说明是SELinux问题 - 生产环境应修复上下文，而非关SELinux：
sudo semanage fcontext -a -t mysqld_db_t "/var/lib/mysql(/.*)?"，然后sudo restorecon -Rv /var/lib/mysql - Ubuntu用户注意AppArmor：检查
/etc/apparmor.d/usr.sbin.mysqld是否允许目标路径，必要时更新配置并sudo systemctl reload apparmor
用--user=mysql参数却还是权限错？检查父目录链的属主
MySQL要求从根路径到 datadir 的每一级父目录，属主都得是 mysql 或至少可被 mysql 进程 traverse（执行 x 权限）。比如 datadir = /data/mysql，但 /data 是 root:root 755，MySQL仍可能因无法进入 /data 而失败。
- 检查命令：
namei -l /data/mysql，看每层属主是否合理 - 若
/data不归mysql，不要盲目chown -R整个/data，只需确保/data对mysql用户有x（执行）权限（即目录本身至少是755且组/其他有x） - 极端情况（如云主机挂载盘）：挂载点属主为
root且不可改，可用bind mount或调整my.cnf把datadir放到已有合适权限的子路径下
/var/lib/mysql 本身，而在它的上一级目录、socket 目录、日志路径，或者 SELinux/AppArmor 的隐形拦截——日志里那条被拒绝的路径，才是你该盯死的目标。 
