必须执行systemctl enable --now mysqld实现开机自启并立即启动，再用systemctl is-active mysqld确认active状态；mysql_secure_installation是强制安全基线，须用临时密码登录后删除匿名用户、禁远程root、移除test库。
MySQL 8.0 在 Rocky Linux 9 上默认不自启，也未启用任何安全策略——直接运行 systemctl enable mysqld 只是注册服务，mysql_secure_installation 才是真正关掉裸奔状态的关键动作。
开机自启动必须用 --now 启动并验证状态
Rocky Linux 9 使用 systemd，仅 systemctl enable mysqld 不会立即启动服务，且容易误以为“已生效”。必须一步到位：
- 执行
systemctl enable --now mysqld：同时启用开机自启 + 立即启动 - 检查是否真在运行：
systemctl is-active mysqld（返回active才算成功） - 别只看
systemctl status mysqld的绿色文字——它可能显示 loaded but inactive，说明没真正跑起来 - 若报错
system has not been booted with systemd as init system，说明你正在 WSL2 里没启用 systemd 模式，需改用wsl --update && wsl --shutdown后重启发行版
mysql_secure_installation 不是可选项，是强制安全基线
MySQL 8.0 初始化后 root 密码为空？错。它生成的是临时密码，且默认禁用空密码、匿名用户、test 库、远程 root 登录——但这些全是靠 mysql_secure_installation 显式触发的。跳过等于交出数据库控制权：
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 必须先用
grep 'temporary password' /var/log/mysqld.log拿到初始密码，否则连第一步都进不去 - 脚本中「Remove anonymous users?」必须选
y，否则任意用户可无密码连接 - 「Disallow root login remotely?」生产环境建议
y；若真需远程管理，不要开root@'%'，而是单独建admin@'192.168.1.100' - 「Remove test database and access to it?」选
y——这个库默认允许任意用户读写，是典型攻击入口
SELinux 和 WorkingDirectory 容易导致静默启动失败
Rocky Linux 9 默认开启 SELinux，而 MySQL 8.0 的 systemd 单元文件（/usr/lib/systemd/system/mysqld.service）里 WorkingDirectory 默认设为 /var/lib/mysql。一旦你改过数据目录（比如挪到 /data/mysql），但没同步改 systemd 配置，mysqld 就会因工作目录不存在而静默退出——journalctl -u mysqld 里甚至看不到错误，只有一行 Failed with result 'exit-code'：
- 检查当前配置：
systemctl show mysqld | grep WorkingDirectory - 若路径不匹配，用
systemctl edit mysqld覆盖该值，例如写入：[Service] WorkingDirectory=/data/mysql
- 然后重载并重启：
systemctl daemon-reload && systemctl restart mysqld - SELinux 报错常见于
setroubleshoot日志，若启动失败又无明确提示，先运行ausearch -m avc -ts recent | audit2why看是否被策略拦截
远程访问不是配完 bind-address 就完事
很多人把 bind-address = 0.0.0.0 加进 /etc/my.cnf 就以为能连了，结果 telnet 3306 超时——漏了两个关键点：
- 防火墙必须放行：
firewall-cmd --permanent --add-port=3306/tcp && firewall-cmd --reload，Rocky 9 默认启用 firewalld - MySQL 用户权限是 host-specific 的：
CREATE USER 'app'@'192.168.1.50' IDENTIFIED BY 'xxx'; GRANT SELECT ON db.* TO 'app'@'192.168.1.50';，用'app'@'%'是高危操作 - 别忘了
skip-name-resolve：若 DNS 不通，首次连接会卡 30 秒，加在[mysqld]段下可绕过反向解析 - 确认端口监听：
ss -tlnp | grep :3306，输出中应有*:3306而非127.0.0.1:3306
真正麻烦的从来不是命令敲不对，而是某个配置项没生效、某条策略没触发、某个目录权限没同步——这些地方一漏，服务就处在“看似正常、实则裸奔”的状态。
