生产环境优先选官方RPM（CentOS/RHEL）或DEB（Ubuntu/Debian）包，因其自动配置systemd、用户、SELinux/AppArmor及默认my.cnf；需非标路径、多实例或容器部署时才用官方二进制包。
生产环境该用 RPM 还是二进制包？
生产环境优先选官方 mysql-community-server RPM 包（CentOS/RHEL）或 DEB 包（Ubuntu/Debian），不是因为“省事”，而是它自动注册 systemd 服务、创建 mysql 用户、配置 SELinux/AppArmor 策略、生成默认 /etc/my.cnf，且升级时能保留配置和数据目录结构。
但要注意：rpm -i 默认把数据目录定死在 /var/lib/mysql，改路径不能靠安装参数；更可靠的做法是安装后修改 /etc/my.cnf 中的 datadir，再手动迁移数据并调整目录属主为 mysql:mysql。
如果你需要把 MySQL 装在非标准路径（比如 /data/mysql8）、或一台机器跑多个实例、或想跳过系统包管理器干预（例如容器内部署），就直接用二进制包 —— 官方提供的 mysql-8.0.xx-linux-glibc2.17-x86_64.tar.xz 是最稳妥的选择。
什么情况下才该碰源码编译？
除非你明确需要以下某一项：cmake 编译时启用特定加密算法（如 libressl 替代 openssl）、禁用不需要的存储引擎（比如彻底去掉 FEDERATED）、适配 ARM64 且官方没提供对应二进制包、或要打定制 patch 测性能。
否则源码编译就是给自己加戏：MySQL 8.0.33+ 要求 cmake >= 3.20，漏装 ncurses-devel、openssl-devel、zlib-devel 就卡在 configure 阶段；mysqld --initialize 失败大概率是 datadir 权限没设对，或 SELinux 没关/没调策略；后续升级基本等于重来。
常见误判点：性能更好 是理论值，实际线上负载下，RPM 和二进制包与源码编译版的 QPS 差距通常小于 3%，远不如 schema 设计或索引优化带来的收益。
二进制包初始化时最容易错哪几步？
二进制包解压后不能直接启动，必须显式初始化数据目录。这步出错率极高，核心就三件事：
-
groupadd mysql && useradd -r -g mysql -s /bin/false mysql—— 必须用-r创建系统用户，否则mysqld启动时会拒绝以普通用户身份写数据目录 -
bin/mysqld --initialize --user=mysql --basedir=/opt/mysql --datadir=/opt/mysql/data——--user参数不能省，且datadir目录需提前chown mysql:mysql - 首次启动前确认
my.cnf中没有残留的skip-grant-tables或错误的socket路径，否则systemctl start mysqld会静默失败
初始化成功后，临时 root 密码在日志里：grep 'temporary password' /opt/mysql/data/error.log，不是 /var/log/mysqld.log —— 这个路径只适用于 RPM 安装。
RPM 卸载会不会丢数据？
会，但取决于你怎么卸载。
rpm -e mysql-community-server 只删程序文件，/var/lib/mysql 完整保留；而 apt remove mysql-server（Debian/Ubuntu）默认也保留数据，但加 --purge 才清配置和数据目录。
真正危险的是：有人卸载后重装 RPM，以为会自动复用旧数据目录，结果 mysqld 启动时发现 datadir 不为空却没做 upgrade，直接报错退出。此时必须手动执行 mysql_upgrade -u root -p（MySQL 5.7）或依赖 mysqld --upgrade=FORCE（MySQL 8.0+），否则实例起不来。
所以哪怕用 RPM，也要养成习惯：每次变更前先备份 /var/lib/mysql 的硬链接或 LVM 快照，而不是依赖“卸载不删数据”这个模糊认知。
