MySQL 5.7 升级到 8.0 需满足三大硬性门槛：CentOS 7+ 系统、ext4 或开启 barrier=1 的 xfs 文件系统、以及 mysqld 对 libatomic 等新依赖；缺一将导致服务无法启动。
直接说结论：MySQL 5.7 升级到 8.0 不是“换二进制就能跑”，环境层面有三个硬性门槛必须提前确认——系统版本兼容性、文件系统限制、以及最关键的 mysqld 启动依赖变化。忽略任一都可能导致服务根本起不来。
CentOS 7 或更高版本才是安全基线
MySQL 8.0.27+ 官方仅提供对 CentOS/RHEL 7 及以上（含 Rocky/AlmaLinux）的完整支持；CentOS 6 已彻底不兼容，连 systemd 单元文件都无法加载。即使强行编译或降级依赖，也会触发 glibc 版本冲突，报错如 /lib64/libc.so.6: version `GLIBC_2.18' not found。
- 检查命令：
cat /etc/redhat-release和ldd --version - 若为 CentOS 6，必须先升级 OS 或改用容器化部署（如 Docker 官方
mysql:8.0镜像） - 注意：某些云厂商的“CentOS 7 兼容模式”虚拟机仍可能缺
libatomic，需手动yum install libatomic
ext4 是底线，xfs 要确认 barrier 支持
MySQL 8.0 默认启用 innodb_flush_method=O_DIRECT，这对底层文件系统提出明确要求：必须支持 direct I/O 的原子写入语义。ext3 已被实测证实会引发 InnoDB: Assertion failure 崩溃；xfs 虽可用，但若内核未开启 xfs mount option barrier=1（尤其在旧版 CentOS 7.2 之前），可能造成 WAL 日志写入不一致。
- 验证方式：
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep -o 'xfs\|ext4' - ext4 用户无需额外操作；xfs 用户执行：
sudo xfs_info /var/lib/mysql，确认输出含</li> <li>SSD/NVMe 设备上禁用 barrier（<code>barrier=0
）可提升性能，但必须配合 UPS 或电池背板，否则断电即丢事务
systemd 服务单元和 socket 激活机制已变更
MySQL 8.0 不再使用 mysqld_safe，而是通过 systemd 的 mysqld.service 直接管理进程生命周期。这意味着：原 /etc/init.d/mysqld 脚本完全失效；若残留 mysql.sock 文件且权限不对（如属 root:root），systemctl start mysqld 会静默失败，日志只显示 Can't start server: Bind on unix socket。
- 关键动作：升级前运行
sudo rm -f /var/run/mysqld/mysqld.sock /tmp/mysql.sock - 检查
/usr/lib/systemd/system/mysqld.service中User和Group是否为mysql（5.7 有时设为root，8.0 强制非 root） - 若用 socket 激活（
mysqld.socket），需确认ListenStream=/var/lib/mysql/mysql.sock路径与socket配置项一致，否则客户端连接报Can't connect to local MySQL server through socket
最易被跳过的点：很多团队只关注 SQL 兼容性和配置迁移，却忘了 /var/lib/mysql 目录的 SELinux 上下文在 8.0 启动时会被重新校验。哪怕目录权限全对，sestatus -v 显示 enforcing 状态下，mysqld 仍可能因 avc: denied { write } for comm="mysqld" name="ib_logfile0" 拒绝启动——此时不是改配置，而是要 restorecon -Rv /var/lib/mysql。
