物理备份恢复后MySQL启动失败，90%是文件系统权限未对齐，须严格按属主（chown -R mysql:mysql）、权限（chmod 750）、SELinux/AppArmor上下文（chcon -R -t mysqld_db_t）三层逐级修复，缺一不可；务必先确认真实datadir路径并验证每层访问权限。
物理备份恢复后MySQL启动失败，90%是文件系统权限没对齐，不是配置或SQL问题——必须按属主、权限、SELinux三层逐级修复，跳过任一环节都会白忙。
确认真实datadir路径和当前属主
别凭经验改/var/lib/mysql。先停服务：sudo systemctl stop mysqld（注意服务名可能是mysql或mysqld），再查MySQL实际读的目录：sudo mysqld --verbose --help 2>/dev/null | grep "datadir"。输出类似datadir /www/server/data才是真路径。
接着检查该路径现状：ls -ld /www/server/data看顶层属主，ls -l /www/server/data/ibdata1看关键文件属主。常见错误是root:root、backup:backup或www:www——这些组合MySQL进程一律拒绝访问。
- MySQL 8.0+ 启动时会递归校验整个
datadir树的归属，只改顶层目录无效 - 若系统无
mysql用户，先执行：sudo useradd -r -s /bin/false mysql - 严禁用
root:mysql或mysql:root——InnoDB在加载mysql.plugin表时会卡死，报Can't open the mysql.plugin table
递归重设属主并严格限制权限
执行：sudo chown -R mysql:mysql /www/server/data（路径替换成你上一步查到的）。这步必须做，物理恢复用cp -r或rsync几乎必然保留原属主。
然后设权限：sudo chmod 750 /www/server/data。750含义：属主可读写执行、属组可读执行、其他人无任何权限。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- MySQL 8.0+ 对
datadir权限变严格，755或777会直接拒绝启动，日志里出现secure-file-priv警告后秒退 - 子目录（如
mysql/、sys/）会继承父目录权限，不用单独chmod - 严禁
chmod 777——等于把数据库大门敞开，且MySQL自身会主动拒绝启动
检查SELinux或AppArmor是否静默拦截
即使chown和chmod全对，Linux安全模块仍可能拦住MySQL。先查状态：sestatus（CentOS/RHEL）或aa-status（Ubuntu）。
若SELinux启用，补上下文：sudo chcon -R -t mysqld_db_t /www/server/data；若AppArmor启用，检查/etc/apparmor.d/usr.sbin.mysqld是否包含该路径的读写规则。
- Windows用户注意：
NETWORK SERVICE账户必须有“完全控制”权限，普通用户权限再高也没用 - 别信GUI界面显示的“已继承”，需右键→属性→安全→高级→取消勾选“从父项继承权限”再手动添加
- 挂载选项（如
noexec、nosuid）也可能导致errno 13，用mount | grep $(df . | tail -1 | awk '{print $1}')确认
验证修复是否真正生效
重启前先模拟MySQL进程访问：sudo -u mysql ls -l /www/server/data。若返回Permission denied，说明某层权限还没到位。
启动后立即验证：mysql -u root -e "SELECT USER();"应返回root@localhost，而不是Access denied；再执行：SELECT 1 FROM mysql.user LIMIT 1;确认权限表能正常查询。
- systemd环境下还要检查
ProtectHome=yes是否拦截：sudo journalctl -u mysqld -n 30 --no-pager中若见Operation not permitted，就得在/etc/systemd/system/mysqld.service.d/override.conf里加ProtectHome=no - 配置文件加载顺序常被忽略：用
mysqld --verbose --help | grep "Default options"确认生效的是哪份my.cnf，宝塔用户重点盯/www/server/mysql/my.cnf - 真正麻烦的点不在
ibdata1本身，而在它的父目录权限、属主、SELinux上下文三者必须同时满足；漏掉任一，mysqld都会在启动早期静默失败，日志里可能只有一行模糊报错
