现代 Linux 发行版默认使用 systemd，直接执行 systemctl enable mysqld（或 mysql）启用开机自启；需先用 systemctl list-unit-files | grep -i mysql 确认真实服务名，若无输出则属二进制部署，须手动创建 /etc/systemd/system/mysqld.service 并运行 daemon-reload。
现代 Linux 发行版（CentOS 7+/RHEL 7+、Ubuntu 16.04+、Debian 8+）默认使用 systemd，直接启用预置的 MySQL 服务单元即可，无需手写启动脚本；只有二进制部署或老系统（SysV init）才需要手动配置脚本。
确认 MySQL 服务名再操作
服务名不是固定的，mysqld 和 mysql 都可能出现，取决于发行版和安装方式。硬写 systemctl enable mysql 很可能报错“no such unit”。
- 运行
systemctl list-unit-files | grep -i mysql查看真实服务名，常见输出是mysqld.service或mysql.service - 如果返回为空，说明没注册 systemd 单元——大概率是二进制解压安装，跳到下一节处理
- 部分环境（如 CentOS 7 官方 RPM 包）服务名是
mysqld，但 Ubuntu 的 APT 安装默认是mysql，别凭经验猜
用 systemctl enable 启用自启（推荐，95% 场景适用）
只要 systemctl list-unit-files 能看到对应服务名，就走这条路径。它本质是创建符号链接，安全、可逆、兼容性好。
- 假设查到服务名为
mysqld.service：运行sudo systemctl enable mysqld - 启用后验证：
sudo systemctl is-enabled mysqld应输出enabled - 立即测试启动：
sudo systemctl start mysqld，再用sudo systemctl status mysqld看是否 active (running) - 若启动失败，重点看日志：
sudo journalctl -u mysqld -n 50 -e，常见原因是datadir权限不对或my.cnf路径错误
二进制部署必须手写 mysqld.service
如果你是解压 mysql-8.0.33-linux-glibc2.12-x86_64.tar.xz 这类包并手动初始化的，系统没有预置单元文件，systemctl 找不到服务。这时得自己写一个 /etc/systemd/system/mysqld.service。
-
ExecStart必须指向真实的mysqld_safe或mysqld二进制路径，例如/opt/mysql/bin/mysqld_safe，不能只写mysqld_safe -
User和Group必须设为运行 MySQL 的系统用户（通常是mysql），否则启动会因权限被拒绝 - 写完要执行
sudo systemctl daemon-reload，否则enable无效 - 示例关键段：
[Service] Type=forking User=mysql Group=mysql ExecStart=/opt/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf --user=mysql Restart=on-failure
别碰 /etc/rc.d/rc.local（兼容性差，易失效）
虽然网上大量教程教你在 /etc/rc.d/rc.local 里加 service mysqld start，但这在多数新系统上已不可靠：rc.local 默认不执行、SELinux 可能拦截、systemd 会忽略它，且无法感知 MySQL 进程是否真正就绪。
- 除非你明确在用非常老的 CentOS 6 或禁用 systemd 的定制系统，否则不要选这条路
- 即使启用，也必须确保
/etc/rc.d/rc.local有可执行权限：sudo chmod +x /etc/rc.d/rc.local - 该方法无法做依赖管理（比如等网络就绪后再启动 MySQL），故障时无日志追踪能力
真正容易被忽略的是：启用自启 ≠ 服务一定能启动成功。每次 enable 后务必手动 start 并 status 验证，尤其注意 datadir 所有者是否为 mysql 用户、my.cnf 中的路径是否真实存在——这两个问题占启动失败案例的七成以上。
