RPM升级常致mysqld启动失败，因覆盖文件却不迁移配置：废弃参数（如query_cache_type）、插件路径斜杠敏感、systemd未重载；编译升级需显式指定安装与数据目录；8.0+弃用mysql_upgrade，改用--upgrade=FORCE；备份须兼顾逻辑与物理，且注意SELinux上下文。
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，避免连错旧实例
mysql_exec_t 标签，而手动编译安装的二进制默认是 unconfined_exec_t，setsebool -P mysql_connect_any on 都救不了权限拒绝。 
