MySQL权限问题核心在于初始化与服务运行用户上下文不匹配：必须用sudo -u mysql mysqld --initialize --user=mysql初始化，并确保/var/lib/mysql属主为mysql:mysql，同时检查ProtectHome限制和配置文件权限（644且root:root）。
直接用 sudo 执行安装命令，不等于解决了权限问题——它只是把错误从“你没权限”推到了“MySQL 进程没权限”。关键在初始化和启动阶段的用户上下文是否匹配。
mysqld --initialize 必须以 mysql 用户身份运行
很多报错出现在 mysqld --initialize 阶段，比如：Can't create/write to file '/var/lib/mysql/ibdata1'。即使你加了 sudo，如果命令实际由 root 启动，生成的文件属主就是 root:root，后续 systemd 拉起的 mysqld 进程默认以 mysql 用户运行，自然被拒绝访问。
- 错误做法：
sudo mysqld --initialize --datadir=/var/lib/mysql - 正确做法：
sudo -u mysql mysqld --initialize --datadir=/var/lib/mysql --user=mysql - 必须显式传
--user=mysql，否则初始化时仍可能忽略上下文 - 初始化前确保目录已存在且属主正确：
sudo chown -R mysql:mysql /var/lib/mysql
systemd 服务单元里 ProtectHome=yes 会拦住 /var/lib/mysql
CentOS/RHEL 8+ 或 Ubuntu 22.04+ 默认启用 ProtectHome=true，而 /var/lib/mysql 在 /var/lib 下，恰好落在 ProtectHome 的保护路径范围内（该选项实际保护的是 /home、/root、/run/user，但部分发行版策略扩展误伤了 /var/lib）。现象是 journal 日志只显示 Operation not permitted，无具体路径提示。
- 查配置：
systemctl cat mysqld | grep ProtectHome - 临时调试：运行
sudo systemctl edit mysqld，写入：[Service] ProtectHome=false
- 生产环境不要关，应改用
ReadWritePaths=/var/lib/mysql显式放行
配置文件权限过宽也会触发拒绝启动
MySQL 启动时会校验 /etc/my.cnf 或 /etc/mysql/my.cnf 的权限。如果设成 664 或更宽松（比如组/其他用户可写），它会直接退出并报错：File './my.cnf' is not readable 或静默失败。
- 正确权限：
sudo chmod 644 /etc/my.cnf - 正确归属：
sudo chown root:root /etc/my.cnf - 别漏掉包含文件，比如
/etc/mysql/conf.d/下的*.cnf，同样需满足644+root:root - 若自定义了
!includedir，整个目录也得检查权限
最常被跳过的一步：初始化后没清空旧数据目录就重试。残留的 ib_logfile* 或 auto.cnf 可能带 root 权限，导致新初始化卡在第一步。动手前先确认 /var/lib/mysql 是空的，或彻底 rm -rf 再 chown。
