MySQL以非root用户启动需满足：数据目录和socket路径属主为该用户且权限正确；my.cnf中显式配置user、datadir、socket等参数；systemd服务中关闭ProtectHome和NoNewPrivileges并授权ReadWritePaths；SELinux/AppArmor需额外放行。
MySQL 启动时用非 root 用户运行的必要条件
MySQL 服务进程本身不需要 root 权限启动，但必须满足两个硬性前提：数据目录（datadir）和套接字文件（socket）路径的所有者是目标用户，且该用户对这些路径有完整读写权限。否则 mysqld 启动直接失败，报错类似 Can't create/write to file '/var/lib/mysql/is_writable_test' (Errcode: 13 - Permission denied)。
- 确认数据目录归属：
chown -R mysql:mysql /var/lib/mysql（假设目标用户为mysql） - 检查 socket 目录（通常是
/var/run/mysqld或/tmp）是否可写：ls -ld /var/run/mysqld，若不存在则手动创建并赋权：mkdir -p /var/run/mysqld && chown mysql:mysql /var/run/mysqld - 避免把
datadir设在/root或其他仅 root 可写的路径下——非 root 用户根本进不去
my.cnf 中必须显式指定用户和路径参数
仅靠系统服务管理器（如 systemd）切换用户不够，MySQL 自身启动时会校验配置中的 user 和路径设置是否与实际运行环境一致。若不匹配，它可能静默降权失败或拒绝启动。
- 在
[mysqld]段落中强制声明：user = mysql - 显式写出所有关键路径，不要依赖默认值：
datadir = /var/lib/mysql、socket = /var/run/mysqld/mysqld.sock、pid-file = /var/run/mysqld/mysqld.pid - 如果使用 AppArmor/SELinux，需额外放行目标用户的访问策略，否则即使文件权限正确也会被内核拦截（常见于 Ubuntu/CentOS）
systemd 服务文件里不能只靠 User= 就以为万事大吉
很多用户改了 User=mysql 就以为搞定了，结果启动报 Failed at step USER spawning /usr/sbin/mysqld: No such process。这是因为 systemd 默认启用 ProtectHome=true 和 NoNewPrivileges=true，会阻止 mysqld 访问 /var/lib/mysql 或加载动态库。
- 在
/etc/systemd/system/mysqld.service的[Service]段落中关闭保护：ProtectHome=false、NoNewPrivileges=false - 添加
ReadWritePaths=/var/lib/mysql /var/run/mysqld显式授权路径 - 修改后必须执行：
systemctl daemon-reload && systemctl restart mysqld，否则配置不生效
验证是否真以非 root 运行成功
别只看 ps aux | grep mysqld 显示的用户名——它可能只是父进程，真正干活的子进程仍可能是 root。要看实际处理连接的 mysqld 主线程 UID。
- 查进程真实 UID：
ps -eo pid,user,comm,args | grep mysqld | grep -v "mysqld_safe"，确认最靠前那个mysqld行的 user 列是mysql而非root - 连上 MySQL 后执行：
SELECT USER(), CURRENT_USER();—— 这俩返回的是客户端登录身份，和服务器运行身份无关，别混淆 - 检查错误日志开头几行，正常会有类似
mysqld started by uid 106（106 是 mysql 用户的 UID），这是最可靠的依据
最容易被忽略的是 socket 目录的 SELinux 上下文或 AppArmor 规则——权限看着全对，但内核拦着不让写，日志里只报模糊的 “Permission denied”，得去查 ausearch -m avc -ts recent 或 dmesg 才能定位。
