聊到在 Linux 上装 MySQL 8.0很多人第一反应就是yum install mysql-server或者去官网拖一个二进制包解压完事。但我实际接触过的不少环境最后还是老老实实走了一遍源码编译安装倒不是故意跟自己的时间过不去而是定制需求、内网限制、系统版本差异这些东西会让很多偷懒方案在中途变得反而更麻烦。这篇文章就以 CentOS 7、CentOS Stream 8/9 为例把源码编译安装 MySQL 8.0 的完整链路讲清楚从环境体检、CMake 配置到首次启动再到 CentOS 上特有的 SELinux 和防火墙坑我都会按实际踩过的顺序来聊。如果你需要做字符集定制、想绕开官方 Yum 源、或者恰好拿到一台只能离线构建的机器这篇文章应该正好能派上用场。1. 四种安装方式凭什么选虐心的源码编译1.1 不做选择的后果CentOS 默认源里的 MySQL 并不是你以为的 MySQL先说一个很容易被忽略的事实CentOS 7 的默认软件源里根本没有 MySQL 8.0默认提供的是 MariaDB 5.5。CentOS Stream 8/9 的情况类似默认源里同样是 MariaDB 的分支版本而不是 Oracle 的 MySQL 8.0。很多人输了一条yum install mysql-server装出来一看版本号不对再一查才发现系统给装的是 MariaDB 兼容包虽然客户端命令都叫 mysql但底层引擎和个别行为已经不一样了。那有人会说我用 MySQL 官方提供的 Yum 源不就行了确实可行这也是大多数联网环境下最快的路径。但官方 Yum 源有一个隐含前提目标机器能访问官方仓库。内网生产环境、有合规要求不能外开的机器以及离线机房这一招直接失效。还有一种情况是运维规范要求所有软件都必须落在指定目录比如/usr/local/mysql不能随便往系统盘塞官方 Yum 源虽然也能做到 part 安装但定制程度有限。二进制解压包是另一条常见路把mysql-8.0.x-linux-glibc2.17-x86_64.tar.xz解压后初始化数据目录就能用速度很快也是我平时搭开发环境的首选。但二进制包的问题在于它是一把锁死的万能钥匙编译时默认开启了哪些插件、字符集默认规则、是否带 systemd 支持都已经被官方预设好了。你很难在不解构整个包的前提下往里面塞一个自定义插件或者强制把编译参数改成适合当前硬件环境的版本。1.2 源码编译到底解决了什么问题源码编译安装最核心的价值就是四个字可控、可定制。MySQL 8.0 在 CMake 阶段暴露了大量开关从默认字符集、字符集校对规则到是否启用某些存储引擎、是否需要 systemd 集成、是否带调试模式都可以在编译之前定下来。对于需要长期维护、希望安装路径和编译行为都符合内部规范的生产环境这种可控性远远比省那几十分钟来得重要。另外源码编译能够更好地匹配当前系统的运行库。举个例子同一个 glibc 版本在不同发行版上对二进制兼容性的要求很苛刻官方编译的二进制包虽然针对主流 glibc 做过兼容但如果系统里某些底层库版本太老跑起来依然会出现各种GLIBC_2.28 not found的幺蛾子。自己编译的好处在于链接器和运行库都是当前系统上真实存在的版本踩坑的概率会明显低一些。还有一个现实问题是部分环境对软件安装有严格的目录限制和审计要求源码编译允许你通过CMAKE_INSTALL_PREFIX把整个 MySQL 装到任意自定义目录后期想迁移、想整体打包交给运维都比较方便。这些需求叠加在一起就足以解释为什么有人愿意在编译上花掉一小时也不愿意后面面对一堆不可控变量。1.3 关于 CentOS 7 和 Stream 8/9 的系统差异既然标题里写了 CentOS 7、Stream 8/9 为例就有必要把这几个系统在编译 MySQL 时的差异讲清楚。CentOS 7 用的还是古老的 yum 包管理器gcc 默认版本是 4.8.5cmake 默认版本更是老到没法用通常需要手动装新版 cmake。CentOS Stream 8/9 用的是 dnfgcc 版本分别为 8.x 和 11.xcmake 也新得多编译时遇到的底层问题会少很多。三个系统的 glibc 版本也不同。CentOS 7 的 glibc 是 2.17CentOS Stream 8 是 2.28CentOS Stream 9 是 2.34。MySQL 8.0 官方二进制包通常要求 glibc 2.17 以上所以 CentOS 7 上跑官方包没问题但如果哪天你想在更老的系统上编译就会遇到编译链中的各类版本兼容问题。我习惯先把这些版本信息记到本子上因为后面 CMake 阶段一旦失败70% 的报错都能往版本不匹配上靠。对比项CentOS 7CentOS Stream 8CentOS Stream 9包管理器yumdnfdnf默认 gcc4.8.58.x11.x默认 cmake2.8.123.203.20glibc2.172.282.34默认 OpenSSL1.0.2k1.1.1k3.0.xCentOS 7 上最大的痛点就是 cmake 版本。MySQL 8.0 的在很多版本中要求 CMake 3.0 以上而系统自带 2.8 根本过不了检查。后面我会专门讲怎么处理这个问题这里先留个印象。2. 动手前的系统体检依赖和版本问题2.1 先看这些工具是否缺失我在拿到一台新机器后从来不会直接./configure而是先做一轮体检。编译 MySQL 8.0 需要的底层工具和开发库要比想象中多缺一个都会导致后面的 CMake 检查直接失败。以下是我整理的依赖清单适用 CentOS 7 和 Stream 8/9yum install -y gcc gcc-c make cmake bison ncurses-devel openssl-devel libaio-devel libtirpc-devel pkg-config如果你是 CentOS Stream 8/9把yum换成dnf即可命令不长但我遇到过不少人只装了gcc没装gcc-c结果 CMake 在检查 C 编译器时直接报错。这里有一个很容易被忽略的包叫libtirpc-develMySQL 8.0 的部分版本在编译时依赖 RPC 相关头文件缺少它在最后链接阶段才会爆出tirpc相关错误排查起来比较难受。还有perl。MySQL 的安装脚本和部分工具会用到 Perl虽然编译阶段不一定需要但后面执行mysql_ssl_rsa_setup或者跑官方测试脚本时会用到。建议顺手装上yum install -y perl perl-devel如果你的系统是精简安装可能还会缺autoconf、automake、libtool这类编译辅助工具我也一并装上避免后面遇到莫名其妙的问题。2.2 版本不达标是多数编译失败的真凶依赖工具装齐之后第二个重点是版本。CentOS 7 自带 cmake 2.8.12这版本连 MySQL 8.0 的 CMakeLists.txt 都解析不了更别说通过后面的检查。MySQL 8.0 编译官方要求 CMake 3.0 以上但我实测 3.0 偶尔也会挂建议直接上 3.5 以上。我的做法是如果检测到 cmake 低于 3.5就会去 cmake.org 下载一个源码包编译安装步骤不复杂wget https://cmake.org/files/v3.26/cmake-3.26.4.tar.gz tar xf cmake-3.26.4.tar.gz cd cmake-3.26.4 ./bootstrap make -j4 make install这样装出来的 cmake 会落在/usr/local/bin/cmake而系统老版本在/usr/bin/cmake。注意检查PATH顺序确保which cmake指向的是新版本否则后面 CMake 又走老版本了白辛苦一场。gcc 也需要看一下。CentOS 7 的 gcc 4.8 对 C11 的完整支持有限MySQL 8.0 部分版本特别是 8.0.34 之后编译时可能需要更高版本的编译器。建议在 CentOS 7 上先执行yum install -y centos-release-scl然后通过 SCL 安装较新的 devtoolset比如devtoolset-11yum install -y centos-release-scl yum install -y devtoolset-11-gcc devtoolset-11-gcc-c scl enable devtoolset-11 bash切换之后gcc --version应该能显示 11 开头这样编译时很多新特性就能用了。如果你硬要用 gcc 4.8 去编新版本 MySQL 8.0大概率会撞上internal compiler error或者unknown option这类让人血压升高的报错。OpenSSL 版本也要留神。CentOS 7 默认带的 OpenSSL 1.0.2 偏老MySQL 8.0 某些版本要求 OpenSSL 1.1.1 或更高。如果你在 CMake 阶段指定-DWITH_SSLsystem而系统库太老可能直接报OpenSSL 1.1.1 or newer is required。这时候要么自己编译一个新版 OpenSSL 到/usr/local/openssl要么用 MySQL 源码包自带的 SSL 文件把 CMake 参数改成-DWITH_SSL/usr/local/openssl路径指向你新装的那个版本。3. CMake 配置逐项拆解每个参数都在控制什么3.1 一份能跑的 CMake 命令行依赖检查完毕接下来进入正题。MySQL 8.0 在 8.0.30 之前使用 CMake 作为主构建系统之后依然是所以这里的核心命令就是cmake。我给出一个经过验证的可执行配置模版然后再逐行解释这些参数为什么这样设cmake . \ -DCMAKE_INSTALL_PREFIX/usr/local/mysql \ -DMYSQL_DATADIR/mysql/data \ -DMYSQL_UNIX_ADDR/tmp/mysql.sock \ -DDEFAULT_CHARSETutf8mb4 \ -DDEFAULT_COLLATIONutf8mb4_general_ci \ -DWITH_BOOST/usr/local/boost_1_73_0 \ -DDOWNLOAD_BOOST0 \ -DWITH_SSLsystem \ -DWITH_SYSTEMD1 \ -DWITH_DEBUG0在跑这段命令之前确保你已经位于解压后的 MySQL 源码目录比如mysql-8.0.36。cmake .最后的点表示当前目录也可以写成cmake ..如果你在专门的build子目录中。我习惯单独建一个 build 目录把编译产物和源码隔离开目录结构会更清爽但这不是必须的。3.2 你为什么要这样设置 boostWITH_BOOST是 MySQL 8.0 编译时绕不过去的一个配置项。MySQL 源码内部大量使用了 Boost 头文件中的数据结构与算法库所以构建时需要指定 Boost 源码包的位置。这里的源码包位置指的是解压后的目录而不是系统通过 yum 安装的 boost 库因为官方要求使用特定版本的 Boost 源码同目录避免因为系统 Boost 版本不同导致 ABI 不一致。我有两种获取 Boost 的办法。第一种是提前从 boost.org 下载比如 MySQL 8.0.36 对应 Boost 1.77 左右具体看源码目录下VERSION文件中的说明。下载后解压到指定位置把路径写给WITH_BOOST。第二种是直接把 CMake 参数改成-DDOWNLOAD_BOOST1 -DWITH_BOOST/usr/local/boost这样 CMake 会自动尝试从网络下载匹配版本的 Boost。但如果你是离线环境千万不要依赖 DOWNLOAD_BOOST否则编译过程会卡在下载阶段一直重试。离线机器上我都是提前把 Boost 拷进去。3.3 字符集、sock 文件、安装路径这些细节DEFAULT_CHARSET和DEFAULT_COLLATION决定 MySQL 创建库表时的默认字符集和排序规则。我把字符集设为utf8mb4而不是老的utf8理由是 utf8mb4 才是真正意义的全量 Unicode能覆盖 emoji 和多数生僻汉字。排序规则用utf8mb4_general_ci是最通用、性能也不错的选择。如果你做的是中文业务系统强烈建议在源码阶段就把默认字符集定死省得以后在建库时反复声明还能避免一部分客户端连接时因字符集不一致导致的乱码问题。MYSQL_UNIX_ADDR指定 Unix socket 文件的路径。默认是/tmp/mysql.sock但某些系统/tmp清理策略可能误删 socket 文件导致本机客户端无谓报错。如果公司内部有统一 socket 路径规范可以用这个参数改掉。我习惯保持默认因为大多数客户端工具默认连/tmp/mysql.sock改了反而要到处适配。CMAKE_INSTALL_PREFIX是 MySQL 安装根目录。这里设为/usr/local/mysql好处是整个安装架构清晰后续二进制文件、库文件、头文件、脚本都集中在这个目录下。想卸载就删整个目录想备份就打包整个目录不会被散落一地的文件折腾疯。MYSQL_DATADIR单独指数据目录我强烈建议不要把数据目录放在安装目录里而是放到独立分区或挂载点例如/mysql/data这样升级、备份、磁盘扩容都更灵活。WITH_SYSTEMD1也很关键。这个开关会在安装过程中生成 systemd 服务管理所需的相关文件。有了它你可以直接用systemctl start mysqld管理 MySQL而不是每次手动去敲mysqld_safe。CentOS 7 以上系统都用 systemd所以这个参数值得开。WITH_DEBUG0是为了关闭调试模式减少无谓的性能损耗和日志量。如果你不是要追查 MySQL 源码级问题生产环境不要开 debug。4. 编译的几个小时里你可能会撞上的报错4.1 编译前C compiler cannot create executablesCMake 配置阶段最常见的第一个报错是C compiler cannot create executables。很多人第一反应是编译器坏了其实绝大多数情况是没装gcc-c或者装了但 CMake 找到的编译器版本过低。这时候先执行gcc --version和g --version确认两个命令都有输出。如果没有g装一下gcc-c再回头跑 CMake。还有一种情况是 CMake 本身版本太低在解析项目文件时直接崩溃。CentOS 7 自带 cmake 2.8 会在很早的阶段就报CMake 3.x is required。这个报错相当于把问题写在脸上了照着我前面提到的方法去装一个新版 cmake 即可。装完后一定要重新打开一个 shell让 PATH 环境变量刷新不然还是用旧版本。4.2 编译中Boost 相关报错Boos 相关报错基本长这样Could not find the Boost library、Cant find Boost include directories或者The Boost libraries were not found。这个报错出现的时机可能不是 CMake 一开始而是配置进行到一半因为 MySQL 是逐模块检查依赖的。解决思路很简单确认WITH_BOOST指向的目录里确实有解压好的 Boost 源码目录结构应该顶层就是boost_1_73_0这类文件夹里面能看到boost子目录。把路径写给 CMake 时我一般直接写到包含boost这个子目录的父级路径也就是-DWITH_BOOST/usr/local/boost_1_73_0不要写到 boost 子目录内部。如果你用的是-DDOWNLOAD_BOOST1但机器没有外网那就会卡在下载阶段。它通常会先尝试访问外网超时后报FAILED to download boost。离线环境一定提前把 Boost 包下载好放到可访问的目录或者放到源码目录下的boost/子目录里让 CMake 直接使用本地副本。4.3 链接阶段undefined reference 和 OpenSSL 冲突算下来编译阶段最让人头皮发麻的问题是快结束时某一个.o文件链接报错比如undefined reference to crypt或者undefined reference to EVP_sha3_256。前者往往和缺少libcrypt库有关CentOS 7 上可以执行yum install -y libcrypt解决但要注意libcrypt在不同版本系统里名字略有差别某些系统需要在 CMake 命令里加-DLIBCRYPTO_LIBRARY/usr/lib64/libcrypt.so。后者多半是 OpenSSL 版本不满足要求系统自带库太旧连接阶段找不到新函数符号。碰到这类链接错误第一反应别去改源码先回头看版本。CentOS 7 自带的 OpenSSL 1.0.2 是完全满足不了 MySQL 8.0 后期版本链接要求的。我当时的处理办法是手动编译一份 OpenSSL 1.1.1 到/usr/local/openssl然后 CMake 参数从-DWITH_SSLsystem改成-DWITH_SSL/usr/local/openssl。这样 MySQL 编译时会优先使用新版库的头文件和链接库链接错误基本就消失了。如果你换用 MySQL 8.0 官方二进制包它内部其实已经捆绑了合适的 SSL反而没有这个烦恼。4.4 编译太慢怎么办MySQL 8.0 源码包很大编译一次在配置合理的机器上通常需要 30 到 60 分钟。如果你没有耐心干等可以用make -jN开启并行编译N通常设为 CPU 核心数的两倍以内。比如一台 4 核机器用make -j88 核机器用make -j16。并行参数设太大反而会因内存不足导致进程被系统 kill所以量力而行。并行编译的时候我第一次遇到的现象是内存耗尽后编译进程直接没了还留下一堆部分生成的.o文件。后来我改用make -j$(nproc)的算法先看核心数再决定同时在空闲时段编译就不会再出现 OOM 了。如果你的编译中途失败重新跑make时它会自动跳过已经生成的目标文件从失败点续编这算是源码编译比较友善的一点。5. 首次启动从数据目录到 systemd 自启5.1 创建专用用户和数据目录源码编译完成后安装目录会生成在/usr/local/mysql。但离真正能跑起来还差两步创建专用用户、初始化数据目录。绝对不要直接用 root 用户跑 MySQL 进程这是安全底线。groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /mysql/data chown -R mysql:mysql /mysql数据目录我放在/mysql/data而不是默认的/usr/local/mysql/data原因前面说过为了备份和升级时不动安装目录。这里有一点值得注意如果你打算让 MySQL 在 root 用户下执行某些管理命令目录权限要分配清楚MySQL 主进程以 mysql 用户运行它必须对datadir有完全读写权限否则启动时会报Cannot change permissions of the file。5.2 初始化--initialize 与 --initialize-insecure 的区别初始化数据目录是源码安装和二进制包安装都绕不开的一步。MySQL 8.0 不再推荐mysql_install_db而是用mysqld --initialize或者--initialize-insecure。这两个参数的区别是--initialize会生成一个临时的随机 root 密码写进错误日志文件--initialize-insecure则直接生成一个空密码的 root 账号方便第一次登进去马上改密。我的建议是在内网环境用--initialize-insecure因为拿到随机密码再去翻 error log 有点折腾尤其是第一次接触 MySQL 8.0 的人看到密密麻麻的日志会发慌。不用太担心空密码的安全性因为我们初始化完马上就会改密码。初始化命令参考/usr/local/mysql/bin/mysqld --initialize-insecure --usermysql \ --basedir/usr/local/mysql --datadir/mysql/data执行后如果没有任何输出说明初始化成功了。如果有报错先去看datadir权限和依赖库是否完整还有 SELinux 会不会拦自定义目录写入这个坑我在后面专门讲。5.3 my.cnf 里的关键配置初始化完成后需要写一份配置文件MySQL 5.7 之后默认读取/etc/my.cnf如果你不希望系统里多个 MySQL 实例互相干扰可以在启动命令里用--defaults-file/etc/my.cnf显式指定。下面是我实际用下来比较稳的基础配置[mysqld] usermysql basedir/usr/local/mysql datadir/mysql/data socket/tmp/mysql.sock port3306 pid-file/mysql/data/mysql.pid log-error/mysql/data/mysql.err character-set-serverutf8mb4 collation-serverutf8mb4_general_ci skip-external-locking max_connections500 innodb_buffer_pool_size1Glog-error一定要配。没有错误日志的话MySQL 启动失败时你连原因都看不到。第一个排错动作永远是先看这个文件。innodb_buffer_pool_size建议设为你物理内存的 50% 到 70%但这取决于机器是否还有其他服务不能一刀切。如果你的机器是 4G 内存那 1G 比较合适。5.4 三种启动方式选哪种配置好文件后有三种启动方式。第一种是直接运行/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf 这种方式前台会占用一个终端适合临时检查不适合生产。第二种是mysqld_safe/usr/local/mysql/bin/mysqld_safe --defaults-file/etc/my.cnf mysqld_safe会额外启动一个监控进程如果 mysqld 意外退出它会尝试重新拉起适合当守护进程用。第三种是我最推荐的在编译时开了-DWITH_SYSTEMD1安装后系统里会包含一个 systemd 服务文件你只需要systemctl enable mysqld systemctl start mysqld systemctl status mysqld如果 systemd 服务文件没被自动生成你可以自己写一个内容大致如下[Unit] DescriptionMySQL 8.0 Afternetwork.target [Service] Typenotify Usermysql Groupmysql ExecStart/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf LimitNOFILE65536 [Install] WantedBymulti-user.target写好后放在/usr/lib/systemd/system/mysqld.service再执行systemctl daemon-reload。注意Typenotify依赖 MySQL 在启动完成时向 systemd 发送通知这对源码安装完全兼容。首次启动成功后执行/usr/local/mysql/bin/mysql -uroot -p因为初始化用的是--initialize-insecure密码直接回车就进去了。进去第一步改密码ALTER USER rootlocalhost IDENTIFIED BY YourPassword;然后建一个普通业务账号CREATE USER app% IDENTIFIED BY AppPassword; GRANT ALL PRIVILEGES ON *.* TO app%; FLUSH PRIVILEGES;我不建议业务账号直接给 root。虽然本地开发怎么搞都行但养成好习惯可以少踩很多权限事故。6. CentOS 上最容易翻车的两个隐形杀手SELinux 与防火墙6.1 权限全对却提示 Permission denied源码安装的 MySQL 目录是自定义路径这正好撞上 CentOS 默认启用的 SELinux 的检查机制。常见表现是权限已经用chown -R mysql:mysql设置好了mysqld 启动却报Permission denied或者Cant open the mysql.plugin table然后启动失败。这种时候第一反应不是去怀疑权限而是先看 SELinux。执行getenforce查看当前状态如果输出Enforcing那基本可以确定 SELinux 在拦截。有两条路可以走。一条是临时关闭不写持久化配置setenforce 0这样可以快速验证是不是 SELinux 的问题。验证 OK 之后再考虑要不要永久关闭。永久关闭需要改/etc/selinux/config把SELINUXenforcing改成SELINUXdisabled然后重启。但我得提醒一句生产环境不要无脑关闭 SELinux。更好的办法是针对 MySQL 目录和端口打上对应的 SELinux 规则这东西配置起来确实有点繁琐而且网上资料又少所以很多人干脆选择关闭。小型内部系统、开发测试机这么做问题不大正式生产环境我建议要么安全团队配合做规则要么干脆用官方 Yum 包安装到默认路径让 SELinux 的策略文件能自动匹配上否则后续会出现很多安全审计层面的麻烦。6.2 远程连不上把 3306 放行的同时还要看 bind-address源码安装的 MySQL 默认监听地址是*也就是所有网卡但 CentOS 防火墙默认不会放行 3306 端口。如果你在公司另一台机器上想远程连接这个 MySQL连之前先做两件事。第一件事确认防火墙放行 3306firewall-cmd --zonepublic --add-port3306/tcp --permanent firewall-cmd --reload firewall-cmd --list-ports执行完--list-ports应该能看到3306/tcp。如果你的系统没有开 firewalld可以检查 iptables很多旧习惯的人用的是 iptables规则就不一样了。第二件事是确认bind-address。在my.cnf的[mysqld]段里默认没写bind-address会监听所有地址但有些人会因为安全习惯加上bind-address127.0.0.1这会导致远程死活连不上。如果你确实需要局域网或公网访问把这个值改成0.0.0.0或者指定内网 IP。验证服务是否真的在监听 3306用ss -tlnp | grep 3306如果输出里有0.0.0.0:3306说明监听正常。远程客户端的连接命令参考mysql -h 192.168.1.100 -P 3306 -uapp -p如果连接超时优先检查防火墙其次检查 SELinux 是否拦了出站连接然后是网络路由。大多数情况下防火墙和 bind-address 这两个因素能解决 90% 的问题。6.3 顺手做一次连接验证我习惯在源码安装完成并启动后第一时间做三层验证。第一层本机 Unix socket 连接验证服务和 socket 地址对不对mysql -uroot -p -S /tmp/mysql.sock第二层本机通过 TCP 协议连接验证 MySQL 本身的网络服务正常mysql -uroot -p -h 127.0.0.1 -P 3306第三层远程客户端或从另一台机器用业务账号连一下验证防火墙和远程权限都到位mysql -h 服务器IP -P 3306 -uapp -p很多人最后一步忘记了授权用户是app%结果用 app 账号远程登录时被 MySQL 拒绝报Host x.x.x.x is not allowed to connect或者干脆密码都对但登录失败。MySQL 的账号是用户名来源主机一起约束的给applocalhost授权的账号只能本机连。所以远程访问之前检查账号授权类型也非常关键。7. 源码安装的维护、升级与卸载7.1 当前安装的编译参数怎么查源码装好之后一段时间后你可能忘了当时到底开了哪些编译选项不用去翻历史命令MySQL 自带的查看方式就够用/usr/local/mysql/bin/mysqld --verbose --help | grep -E character-set-server|basedir|datadir这个命令会把 MySQL 编译时确定的默认参数都打印出来并且标注/usr/local/mysql等路径。如果你想看更底层一点的编译细节可以从CMakeCache.txt里面翻但这个文件只在源码目录里存在安装目录里没有。所以有条件的话建议把当时的源码解压目录和 CMake 参数存到运维文档里以后维护会省很多事。7.2 升级会不会有雷源码安装的升级路径不像 rpm 包那样一条命令解决它需要你重新下载新版源码包重新走一遍 CMake 和 make 安装。但数据目录可以复用因为 MySQL 官方支持从上一个 GA 版本升级到下一个 GA 版本只要你是同一大版本比如 8.0.35 升到 8.0.36直接复用/mysql/data是没问题的。升级时我比较谨慎的流程是先全量备份数据。可以用mysqldump导一份逻辑备份也可以直接冷备整个数据目录mysql -uroot -p -e STOP SLAVE; FLUSH TABLES WITH READ LOCK; tar czf /backup/mysql-data-$(date %F).tar.gz /mysql/data然后停服务、编译新版本、安装到新的/usr/local/mysql-new再调整软链接或my.cnf里的basedir最后启动 mysqld执行/usr/local/mysql-new/bin/mysql_upgrade -uroot -pMySQL 8.0 的升级机制其实比我之前接触的 5.7 要智能化很多很多系统表会自动完成升级不一定需要手动跑 mysql_upgrade但为了稳妥我还是会做一次完整备份。如果是从 MySQL 5.7 跨到 8.0那就别天真地想着原地直接升级了数据字典变化太大最好先导出再导入。7.3 卸磨杀驴时到底要删哪些东西源码安装没有统一卸载命令所以很多人卸不干净后面再装新版时各种冲突。我整理了一个相对完整的删除清单停止服务systemctl stop mysqld删除安装目录rm -rf /usr/local/mysql删除数据目录rm -rf /mysql/data如果确认数据不需要了否则先备份删除配置文件rm -rf /etc/my.cnf以及/etc/my.cnf.d/文件夹删除 systemd 服务文件rm -f /usr/lib/systemd/system/mysqld.service然后systemctl daemon-reload删除 mysql 用户和组userdel mysql; groupdel mysql清理 PATH 里的软链接比如如果你手动创建过/usr/local/bin/mysql这类软链这套流程走完基本就是一个干净的系统状态。我再多说一句如果你是在 CentOS 7 上用了 SCL 安装的 devtoolset 来支持编译卸载 MySQL 时要不要顺手卸载 devtoolset 取决于你是否还需要这个编译器。留着不碍事But 注意别让没用的开发包长期堆积。7.4 谈谈 my.cnf 的常用优化参数安装配置完成、服务跑起来之后接下来就是对参数做一些贴合实际环境的调整。除了前面提到的innodb_buffer_pool_size和max_connections以下几个参数也值得关注[mysqld] innodb_log_file_size512M innodb_flush_log_at_trx_commit2 slow_query_log1 slow_query_log_file/mysql/data/slow.log long_query_time2 log_bin/mysql/data/binlog/mysql-bin binlog_formatrowinnodb_log_file_size调整重做日志文件大小对于频繁写入的业务有直接帮助。innodb_flush_log_at_trx_commit2表示每次事务提交会写入缓存但每秒刷盘一次这种设置在可以接受少量数据丢失的日常业务场景下能明显降低磁盘 IO 压力。如果你做的是强一致性金融类业务那还是别改成 2老老实实用默认的 1。慢查询日志打开后排查线上慢 SQL 会方便很多。我个人习惯把long_query_time设置成 2 秒这样日志量不会太爆炸同时又能捕捉到真正的性能瓶颈。二进制日志log_bin看需求开启做主从复制和 PITR 时间点恢复的时候必须开。注意这里的/mysql/data/binlog目录要先建好并给予 mysql 用户写权限。调优没有万能公式每台机器配置不同业务模型不同。我通常的做法是先采一周的慢查询日志和内存趋势再定最终参数。所以不用迷信网上的所谓标准生产配置一切以实际观测数据为准。8. 写到最后的一点碎碎念源码编译装 MySQL 这条路第一次走会觉得时间很长中间还一堆报错但凡是完整走过几遍的人应该都会喜欢上这种什么都在自己掌控中的感觉。特别是当你碰到一台诡异的 CentOS 7 机器既没有外网又限制了系统目录源码编译反而是最稳的那条路。我个人建议是如果是临时开发环境、快速验证直接上官方二进制包别跟自己过不去如果是长期服务、要做定制参数、有严格目录规范那源码编译今天所做的这些麻烦就是给未来省事。最后再分享一个小技巧编译前把CMakeCache.txt备份一份到/etc/mysql-cmake-options.txt以后任何人接手这台机器都一眼看懂当初的构建参数这种细节在团队协作里特别加分。