mysql启动失败时应优先检查错误日志中的permission denied等系统级拒绝访问提示，确认log_error路径及真实datadir属主为mysql:mysql，再执行chown -r mysql:mysql和chmod 750，最后排查selinux/apparmor拦截。
看错误日志里有没有 Permission denied 或 Can't open
MySQL 启动失败时几乎从不直接说“权限错”，而是卡住或报一堆模糊错误。真正有用的线索藏在错误日志里，比如：Can't open the mysql.plugin table、Operating system error number 2、Permission denied on ./ibdata1、Can't change dir to '/var/lib/mysql/' (Errcode: 13)。这些不是 MySQL 内部逻辑错，全是操作系统拒绝访问的信号。
先定位日志路径：SELECT @@log_error;；如果查不到，常见默认位置是 /var/log/mysql/error.log（Debian/Ubuntu）或 /var/log/mysqld.log（RHEL/CentOS）。别跳过这步——改错目录只会让问题更隐蔽。
确认 datadir 真实路径和当前属主
别信配置文件里写的 datadir，尤其是用了 include 或多配置段时。最可靠的方式是停服务后用 mysqld 自查：
-
sudo systemctl stop mysql（或mysqld，看服务名） sudo mysqld --verbose --help 2>/dev/null | grep "datadir"-
ls -ld /var/lib/mysql（把上一步结果代入）——重点看输出里是root:root、mysql:mysql还是其他组合
如果属主不是 mysql:mysql，后续所有操作都白搭。注意：MySQL 进程默认以 mysql 用户运行，它对 datadir 及其所有子目录/文件必须有读、执行（进入目录）、部分写权限。
chown 和 chmod 必须一起做，且顺序不能反
只改属主不设权限，或只设权限不改属主，都可能失败。正确顺序是：
- 先执行：
sudo chown -R mysql:mysql /var/lib/mysql（路径按你查到的真实值替换） - 再执行：
sudo chmod 750 /var/lib/mysql - 子目录（如
mysql/、performance_schema/）会继承父目录权限，不用单独 chmod
严禁用 chmod 777，哪怕临时测试也不行——MySQL 8.0+ 会主动拒绝启动，并在日志里写 secure-file-priv 相关警告，而不是告诉你“权限太松”。也别用 chown -R $(whoami):$(whoami)，这会让 systemd 因 User=mysql 配置失败。
SELinux 或 AppArmor 开启时，权限修复只是第一步
CentOS/RHEL 或 Ubuntu 启用强制访问控制后，即使 chown 和 chmod 全对，MySQL 仍可能被拦截。典型表现是：错误日志里没有明确权限提示，但服务起不来。
快速验证：
- RHEL/CentOS：
sudo ausearch -m avc -ts recent | grep mysqld - Ubuntu：
dmesg | grep -i apparmor | grep mysqld
若命中，需额外处理策略。例如 CentOS 上可临时放行：sudo setsebool -P mysqld_disable_transitive 1；长期方案是用 audit2allow 生成自定义策略。这步容易被跳过，但恰恰是很多“明明权限对了却还是起不来”的根因。
