MySQL必须用专用非root、无登录能力的系统用户（如mysql）运行，禁用root及可交互账号；需创建useradd -r -s /bin/false mysql，修正数据目录归属，systemd中显式声明User=mysql，并适配SELinux/AppArmor策略。
MySQL进程必须以专用非登录系统用户运行，不能是root，也不能是可交互登录的普通账号——这是生产环境最基础、也最容易被跳过的安全红线。
为什么不能用root或普通登录用户启动mysqld
直接用root启动，等于把数据库漏洞直通宿主机最高权限；而用john这类可登录用户启动，一旦MySQL被攻破（比如UDF提权、本地溢出），攻击者立刻拿到一个shell。这不是假设，是真实攻防中高频失守点。
真正该用的是无登录能力的系统用户：useradd -r -s /bin/false mysql。注意必须用/bin/false，不用/usr/sbin/nologin——某些旧版glibc下nologin可能被绕过。
验证是否生效：getent passwd mysql输出第7字段应为/bin/false；再执行sudo -u mysql bash应立即退出，不进入交互shell。
systemd服务中必须显式声明User=mysql
MySQL 5.7+已弃用mysqld_safe作为默认入口，但很多线上配置仍沿用老写法，在mysqld_safe里加--user=mysql。这会无视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）。
数据目录与路径权限必须同步修正
即使User=mysql写对了，服务也可能静默失败：现象是systemctl status mysqld显示failed to start，日志里只有模糊的Permission denied，没有具体路径。
常见原因有三：
-
/var/lib/mysql及其子目录属主仍是root：执行chown -R mysql:mysql /var/lib/mysql，否则启动报错Operating system error number 13 in a file operation -
pid、socket、log等路径父目录对mysql用户不可写：比如/var/run/mysqld需chown mysql:mysql /var/run/mysqld并确保父目录/var/run允许mysql创建子目录 - SELinux/AppArmor拦截：CentOS/RHEL或Ubuntu上启用强制访问控制时，
ausearch -m avc -ts recent | grep mysqld若看到avc: denied且涉及var_lib_mysql_t，说明策略未放行。临时调试可用setenforce 0，但生产必须修复：semanage fcontext -a -t mysqld_db_t "/home/mysql(/.*)?"再restorecon -Rv /home/mysql
配置文件和SSL证书权限不能宽泛
权限过宽会导致敏感信息泄露或被篡改，mysqld启动时会主动拒绝加载：
-
/etc/mysql/my.cnf（或/etc/my.cnf）必须属root:mysql、权限640：chmod 640 /etc/mysql/my.cnf -
/var/lib/mysql目录权限应为750：chmod 750 /var/lib/mysql - SSL密钥文件如
/etc/mysql/ssl/mysql-key.pem必须是600且仅mysql可读：chown mysql:mysql /etc/mysql/ssl/*.pem && chmod 600 /etc/mysql/ssl/*.pem
这些权限检查是mysqld启动时硬性校验项，漏掉任意一条都可能导致服务无法拉起，且错误提示往往藏在journalctl -u mysqld -n 50末尾几行里，容易被忽略。
