mysql必须用专用低权限系统用户（如mysql）启动，禁用root；需创建无登录能力用户、修正数据目录归属、在systemd service中显式声明user=mysql、适配selinux/apparmor策略，并确保pid/日志/socket路径父目录对mysql用户可写。
MySQL进程不能用root启动，必须用专用系统用户
直接用root运行mysqld等于把数据库和宿主机最高权限绑死——只要服务崩溃或被利用（比如UDF提权、本地溢出），攻击者立刻拿到root shell。这不是理论风险，是真实攻防中高频失守点。
正确做法是创建一个无登录能力的系统用户：useradd -r -s /bin/false mysql。其中-r标记为系统用户，/bin/false确保无法交互式登录。别用nologin，某些旧版glibc下它可能被绕过。
接着必须修正数据目录归属：chown -R mysql:mysql /var/lib/mysql。如果目录里混着root属主的文件（比如初始化时没指定--user），mysqld会拒绝启动并报错Operating system error number 13 in a file operation。
systemd service文件里必须显式写User=mysql
很多线上环境仍沿用老教程，在mysqld_safe里加--user=mysql，但MySQL 5.7+已弃用mysqld_safe作为默认入口，且它会无视systemd的User=设置，强行切回root——加固直接失效。
检查当前配置：systemctl cat mysqld，确认ExecStart=指向的是/usr/sbin/mysqld，不是mysqld_safe。如果不是，编辑/etc/systemd/system/mysqld.service，在[Service]段内强制声明：
User=mysql Group=mysql ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION
改完后执行systemctl daemon-reload && systemctl restart mysqld，再用ps aux | grep mysqld验证主进程UID是否为mysql用户对应ID（通常为27或29）。
SELinux或AppArmor策略必须适配非root用户
即使User=mysql写对了，服务也可能静默失败——尤其在CentOS/RHEL或Ubuntu上启用了强制访问控制。典型现象是systemctl status mysqld显示failed to start，日志里却只有Permission denied，没有具体路径。
查SELinux：运行ausearch -m avc -ts recent | grep mysqld，若看到avc: denied且涉及var_lib_mysql_t或mysqld_etc_t，说明策略未放行。临时调试可setenforce 0，但生产必须修复：用semanage fcontext -a -t mysqld_db_t "/home/mysql(/.*)?"（路径按实际调整）再restorecon -Rv /home/mysql。
AppArmor用户则检查/etc/apparmor.d/usr.sbin.mysqld，确认/var/lib/mysql/** rwk,这类规则存在，且owner /var/lib/mysql/**允许mysql用户读写。
数据目录路径不能放在/root或/home普通用户家目录下
非root部署常有人把datadir设到/home/oper/mysql/data，看似规避权限问题，实则埋雷：一旦该用户被入侵，攻击者可直接修改数据文件或植入恶意表空间；更严重的是，多数发行版的logrotate、backup脚本默认不处理非标准路径，导致备份遗漏或日志轮转失败。
正确路径应选/var/lib/mysql（官方默认）或/opt/mysql/data这类独立挂载点。若必须放/home下，务必确保：chown mysql:mysql /home/oper/mysql且chmod 750 /home/oper/mysql，禁止其他用户进入；同时在my.cnf里显式声明datadir和socket，避免依赖隐式路径查找。
最容易被忽略的一点：mysqld启动时会尝试创建pid文件、错误日志、socket文件，这些路径的父目录必须对mysql用户可写。漏掉任何一个，服务就卡在“starting”状态不动。
