systemd管理mysql自启需确保type匹配进程行为、依赖network-online.target、配置restart防崩溃循环，并通过journalctl查日志而非仅看status；type=simple适用于前台运行的mysqld，type=forking则需配pidfile且路径须一致。
systemd 管理 MySQL 自启不是“配完就完事”，关键在于服务类型匹配、启动时机合理、崩溃后真能拉起——否则 systemctl enable mysqld 只是挂了个名，机器重启后 MySQL 很可能根本没起来。
Type= 必须和 mysqld 实际行为一致
MySQL 官方二进制包或主流发行版（如 RHEL/CentOS 8+、Ubuntu 22.04+）提供的mysqld.service 通常设为 Type=simple，因为现代 mysqld 默认前台运行、不 fork。但如果你用的是旧版 RPM 包或自编译安装，它可能仍走传统 daemon 模式（主进程 fork 后退出），这时必须改用 Type=forking，否则 systemctl start mysqld 会立刻认为启动失败。
- 若
Type=simple下systemctl status mysqld显示 “activating (start)” 卡住几秒后变 “inactive (dead)”，大概率是 mysqld 实际 fork 了，systemd 等不到它“前台就绪” - 若用
Type=forking，必须同时提供PIDFile=，比如PIDFile=/var/run/mysqld/mysqld.pid，且确保该路径可写、目录存在 - 不要强行套用
Type=notify：除非你确认 mysqld 编译时链接了libsystemd并调用了sd_notify()（官方 MySQL 二进制包默认不启用）
依赖 network-online.target 而非 network.target
MySQL 启动时若需绑定公网 IP 或读取远程配置（如 DNS 解析 host 名），只等network.target 不够——它只表示网络接口已配置，不代表路由/域名服务可用。
- 错误写法：
Wants=network.target After=network.target→ MySQL 可能因解析失败而退出 - 正确做法：用
Wants=network-online.target After=network-online.target，并确保底层有systemd-networkd或NetworkManager提供该 target - 验证是否就绪：
systemctl is-active network-online.target返回active才算真正可用
Restart= 策略要防“崩溃循环”
MySQL 崩溃后 systemd 默认不会无限重试，但默认策略（Restart=no）等于放弃守护。必须显式配置：
-
Restart=on-failure：覆盖大多数场景（非 0 退出码、被信号终止） -
RestartSec=10：避免密集重启压垮磁盘或触发内核 OOM -
StartLimitIntervalSec=60和StartLimitBurst=3：60 秒内最多启动 3 次，超限后systemctl status mysqld会显示 “start limit hit”，此时必须人工介入查错（比如磁盘满、my.cnf语法错误、datadir 权限不对）
调试时别只看 systemctl status
systemctl status mysqld 只显示最近一次状态快照，真正错误往往藏在日志里：
- 启动失败后立即执行：
journalctl -u mysqld --since "1 hour ago" -n 50 -o short-precise - 关键线索包括：
Can't start server: Bind on TCP/IP port（端口占用）、Table 'mysql.plugin' doesn't exist（初始化未完成）、Operating system error number 13 in a file operation（权限问题） - 如果日志为空，检查
mysqld是否被 SELinux 拦截：ausearch -m avc -ts recent | grep mysqld
实际中，最常被忽略的是 PIDFile= 路径与 mysqld 实际写入位置不一致，或者 User= 设为 mysql 但 /var/run/mysqld/ 目录属主仍是 root —— 这类细节不报错，只让服务静默失败。
