必须先卸载mariadb-libs，否则mysql-community-libs安装必然失败；需用yum remove而非rpm -e，再运行package-cleanup --problems修复元数据，最后用yum localinstall安装MySQL RPM包并验证版本一致。
必须先卸载 mariadb-libs，否则 mysql-community-libs 安装必然失败——这不是可选项，是 RPM 包管理器的硬性依赖限制。
为什么 yum remove mariadb-libs 是唯一安全起点
CentOS/RHEL 系统预装 mariadb-libs，它提供与 MySQL 兼容的客户端库（如 libmysqlclient.so），但和 mysql-community-libs 文件路径、符号版本完全冲突。RPM 拒绝覆盖安装，报错典型如：file /usr/share/mysql/english/errmsg.sys from install of mysql-community-common conflicts with file from package mariadb-libs。yum remove 会主动检查依赖树，只删 mariadb-libs 及其直连依赖（如 postfix 若未显式依赖该库则不会被连带卸载），比 rpm -e --nodeps 更可控。
- 执行前务必运行
yum deplist mariadb-libs查看哪些包依赖它；若输出中只有postfix或libxml2等通用组件，基本可安全移除 - 避免直接用
rpm -e mariadb-libs：它不解析依赖，容易导致后续yum update失败或系统工具异常 - 卸载后若发现
postfix功能异常，可单独重装：yum reinstall postfix
卸载后必须跑 package-cleanup --problems
卸载 mariadb-libs 后，RPM 数据库可能残留“半破碎”状态，表现为后续安装 MySQL RPM 时提示 Unsatisfied dependencies，即使所有包都已下载齐全。这是因为旧库的文件列表仍被标记为“已安装”，而新包试图写入相同路径。
- 运行
package-cleanup --problems扫描并修复这类元数据不一致 - 若提示
leaves（孤立包），可用package-cleanup --leaves清理无用残留 - 跳过此步直接
rpm -ivh安装 MySQL 包，大概率遇到Failed dependencies卡住
用 yum localinstall 替代逐个 rpm -ivh
MySQL 8.0 的 RPM 包之间有强依赖顺序：mysql-community-common → mysql-community-client-plugins → mysql-community-libs → mysql-community-server。手动按顺序执行 rpm -ivh 极易因遗漏或顺序错乱失败。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 把所有 MySQL RPM 放进同一目录，执行
yum localinstall *.rpm——它自动解析依赖图并按正确顺序安装 - 若提示
Public key not installed，先导入 GPG 密钥：rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql - 强制用
--replacefiles是危险信号：说明仍有文件冲突，应退回检查是否漏卸载mariadb-libs或残留配置
验证是否真干净：查 /usr/lib64/mysql/ 和 rpm -qi
安装完成后不能只信“Success!”，必须确认旧库彻底消失、新库真实落盘。
- 执行
ls -l /usr/lib64/mysql/：输出中不应出现libmariadb.so或任何含mariadb字样的文件；应看到libmysqlclient.so.21（MySQL 8.0 对应版本） - 运行
rpm -qi mysql-community-libs查看安装时间、版本号；再执行rpm -qa | grep mariadb，结果应为空 - 最关键的一步：
mysql --version和mysql -e "SELECT VERSION();"输出必须一致且为8.0.x，否则说明客户端仍在调用旧库缓存
真正麻烦的不是卸载动作本身，而是卸载后残留的元数据和文件路径污染——它们不会报错，但会让后续每一步都悄悄偏离预期。每次操作后多敲两行验证命令，远比重装系统省时间。
