源码编译安装 MySQL 仅在需定制编译选项（如特定加密算法、禁用存储引擎、适配 ARM64 等）时才值得；否则耗时长、依赖多、易出错、升级困难。
源码编译安装 MySQL：什么情况下才值得折腾
除非你明确需要定制编译选项（比如启用特定加密算法、禁用不需要的存储引擎、适配非标准架构如 ARM64 且无官方二进制包），否则不建议从源码编译安装 MySQL。它耗时长、依赖多、出错率高，且后续升级几乎等于重来。
常见踩坑点：
-
cmake版本不兼容（MySQL 8.0.33+要求cmake >= 3.20） - 漏装
ncurses-devel、openssl-devel、zlib-devel等头文件包，导致编译中断 -
make -j$(nproc)并行过高引发内存溢出，尤其在 4GB 内存以下机器上 - 安装后
mysqld --initialize失败，常因datadir权限未设为mysql:mysql或 SELinux 未关闭/策略未调整
二进制免安装包（tarball）：最灵活的生产部署方式
官方提供的 mysql-8.0.xx-linux-glibc2.17-x86_64.tar.xz 是折中选择：不依赖系统包管理器，又能跳过编译，还能自定义安装路径和配置位置。
关键实操要点：
-
解压后必须运行
bin/mysqld --initialize --user=mysql初始化数据目录，否则启动报错Can't start server: Bind on TCP/IP port: Address already in use或直接静默退出 -
my.cnf必须放在/etc/my.cnf、$MYSQL_HOME/my.cnf或~/.my.cnf之一，否则mysqld完全忽略你的配置 - 用
bin/mysqld_safe启动比直接调bin/mysqld更稳妥，它会自动补全缺失的--basedir和--datadir - 若用 systemd 管理，需手写
/etc/systemd/system/mysqld.service，注意Environment="MYSQL_HOME=/opt/mysql"和ExecStart=/opt/mysql/bin/mysqld --defaults-file=/opt/mysql/my.cnf路径一致性
RPM / DEB 包安装：适合快速验证或标准化运维环境
RPM（CentOS/RHEL）和 DEB（Ubuntu/Debian）包由官方维护，自动处理用户创建、服务注册、配置模板和 SELinux/AppArmor 策略，适合 CI/CD 流水线或 Ansible 批量部署。
但要注意：
- RPM 默认将数据目录设在
/var/lib/mysql，若想改路径，必须在rpm -i前用--prefix（仅部分老版本支持），更可靠的方式是安装后修改/etc/my.cnf并迁移datadir - DEB 包在 Ubuntu 22.04+ 上默认启用
mysql-shell自动配置，可能覆盖你手动写的my.cnf，检查/etc/mysql/conf.d/下是否有生成的mysql.cnf - 卸载 RPM 包（
rpm -e mysql-community-server）不会删除/var/lib/mysql，但 DEB 包（apt remove mysql-server）默认保留数据；真正清空需加--purge参数
docker run mysql：开发与测试首选，但别直接上生产
用 docker run --name mysql-dev -e MYSQL_ROOT_PASSWORD=123 -p 3306:3306 -d mysql:8.0 启动最快，5 秒内可用。它本质是基于官方二进制包封装的容器镜像，底层仍是 mysqld 进程。
真实限制很具体：
- 容器内
mysqld默认以mysql用户运行，挂载宿主机目录作datadir时，必须确保该目录属主为999:999（MySQL 官方镜像中mysql用户 UID/GID 固定为 999） -
my.cnf无法通过-v直接覆盖容器内/etc/mysql/my.cnf，因为该路径被声明为 volume；正确做法是挂载到/etc/mysql/conf.d/下的.cnf文件 - 容器重启后
auto.cnf会被重建，导致 GTID 模式下主从复制断裂；生产环境必须用--restart=unless-stopped+ 持久化/var/lib/mysql卷
选哪种方式，取决于你是否需要控制每一个字节——源码编译给你全部权限，也把全部责任推给你；二进制包给你自由和稳定之间的平衡；包管理器和 Docker 则把运维细节藏起来，但藏得越深，出问题时挖得越费劲。
