RPM 升级为什么常导致 mysqld
启动失败
RPM 包升级（如
rpm -Uvh mysql-community-server-8.0.33-1.el7.x86_64.rpm）会覆盖
/usr/bin/mysqld、
/etc/my.cnf模板和 systemd unit 文件，但不会自动迁移或校验你的自定义配置。常见失败点包括：
my.cnf中残留已废弃参数（如
query_cache_type在 8.0+ 被移除），导致
mysqld --validate-config报错 插件路径变更（
plugin_dir从
/usr/lib64/mysql/plugin变为
/usr/lib64/mysql/plugin/末尾斜杠敏感），
INSTALL PLUGIN失败 systemd 服务文件未重载（
systemctl daemon-reload忘记执行），
systemctl start mysqld找不到新二进制路径
手动编译升级时 make install
的关键控制点
源码编译（如 MySQL 8.0.x）不是“替换二进制”那么简单，
make install默认行为极易引发权限与路径混乱： 务必用
-DCMAKE_INSTALL_PREFIX=/usr/local/mysql8显式指定独立安装路径，避免覆盖旧实例 必须同步设置
-DMYSQL_DATADIR=/var/lib/mysql8，否则
mysqld --initialize仍写入旧
datadir，引发元数据不一致
mysql-systemd-start脚本不会自动生成，需手动复制或重写 systemd service 文件，其中
EnvironmentFile和
ExecStart路径必须与编译参数严格匹配
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql8 \
-DMYSQL_DATADIR=/var/lib/mysql8 \
-DDEFAULT_CHARSET=utf8mb4 \
-DDEFAULT_COLLATION=utf8mb4_0900_ai_ci \
-DWITH_BOOST=../boost
升级后 mysql_upgrade
已被弃用，该用什么
MySQL 5.7 之前靠
mysql_upgrade修复系统表结构，但 8.0.16+ 彻底移除该命令。实际升级后必须做的是： 启动新
mysqld时加
--upgrade=FORCE参数（默认是
AUTO，可能跳过必要更新） 确认错误日志中出现
Upgrading system tables.和
Finished upgrading system tables.两行才代表完成 若中途失败，不能反复重启——必须先用
mysqld --no-defaults --bootstrap手动执行
mysql_system_tables.sql等脚本恢复基础表
备份策略在两种升级方式下的实质差异
RPM 升级看似“一键”，但它的原子性仅限于包管理层面；手动编译则完全无回滚机制。二者都绕不开同一底线：
RPM 升级前必须停机并执行mysqldump --all-databases --single-transaction > backup.sql，因为
yum update不保证数据目录兼容性 编译升级前除逻辑备份外，还必须做物理备份：
rsync -aHAX --delete /var/lib/mysql/ /backup/mysql-8.0.33/，因
mysqld --initialize会重置 root 密码且不可逆 无论哪种方式，升级后首次连接必须用
mysql --socket=/var/lib/mysql8/mysql.sock -u root -p显式指定 socket，避免连错旧实例 升级最易被忽略的其实是 SELinux 上下文——RPM 包自带
mysql_exec_t标签，而手动编译安装的二进制默认是
unconfined_exec_t，
setsebool -P mysql_connect_any on都救不了权限拒绝。
