MySQL源码编译这些年做运维和数据库交付我遇到过不止一次这样的需求客户现场是内网环境官方二进制包依赖的glibc和系统不匹配或者安全基线要求自编译、裁剪组件、强制开启某些特性再或者就是想彻底搞懂MySQL构建过程方便后续二次开发和问题排查。每当这种时候“MySQL源码编译”就成了绕不开的环节。本文就从我的实操经验出发把从环境准备、依赖安装、CMake参数配置、编译安装到初始化启动、常见坑位排查的完整过程讲清楚。不管是CentOS、Ubuntu还是其他Linux发行版思路都是通用的。适合刚接触编译安装的初学者也适合需要定制MySQL发行版、做数据库部署和排障的运维、DBA同学参考。内容会偏实操一些所有命令我都尽量给出可直接照抄的版本。1. 为什么非要把MySQL源码编译一遍1.1 源码编译到底解决了什么问题先聊点大实话。官网下载页上明明有现成的二进制包多数生产环境也确实直接解压就能跑但源码编译从来不是没事找事它解决的恰恰是二进制包覆盖不到的场景。第一类是兼容性问题。官方Linux二进制包通常基于比较新的glibc编译比如CentOS 7自带的glibc 2.17在某些新版本二进制包上就可能报“version GLIBC_2.28 not found”。遇到这种环境你又不想升级系统库源码编译就是最现实的路径。第二类是定制需求比如默认字符集、默认排序规则、编译进SSSL库、裁剪掉用不到的存储引擎这些在二进制包上很难改。第三类是内部发布场景很多公司会维护自己的MySQL分支或补丁包这种必然要用源码编译。源码编译还有一个经常被忽略的好处它对整个系统的依赖关系会有更清晰的认识。一次编译下来哪些库是密钥的、哪些是启动时链接的、哪些是运行时动态加载的你都心里有数。这对接下来的性能调优和故障排查帮助很大。1.2 源码包与二进制包、Docker该怎么选很多朋友一听编译就头大问能不能直接用Docker。我的判断标准很简单看部署环境和诉求。如果只是开发环境或测试环境docker pull一把梭是最快的但Docker镜像底层同样是编译好的二进制包逃不掉glibc和openssl的兼容问题只是容器隔离让它不那么明显。如果生产环境有明确的二进制兼容约束或者需要在你自己的基础镜像里安装特定版本MySQL那源码编译的价值就体现出来了。还有个不少团队容易踩的坑在内网环境用Docker镜像仓库没有你想要的MySQL版本标签或者镜像拉不下来这时候离线编译一个版本出来打包成自有的rpm或tar包反而更可控。所以我不建议把源码编译和容器部署对立起来它们是互补的。后面几节我会重点讲编译本身的细节这些经验无论你最终要不要打镜像包都用得上。2. 编译前的准备环境、依赖与源码2.1 准备编译环境MySQL源码编译默认使用CMake构建所以环境上至少需要以下东西操作系统CentOS 7/8、Rocky Linux、Ubuntu 18.04及以上都可以官方推荐64位系统。编译器GCC 7.1及以上MySQL 8.0系列5.7系列用GCC 4.8以上也能编译但为了省事建议尽量用新一点的编译器。构建工具make、cmake。cmake版本要求3.7有些8.0小版本要求更高后面说。各种开发库ncurses-devel、libaio-devel、openssl-devel、bison等。在CentOS/RHEL系统上可以一次性装好yum install -y gcc gcc-c make cmake bison ncurses-devel libaio-devel openssl-develUbuntu/Debian系对应的是apt-get install -y build-essential cmake bison libncurses-dev libaio-dev libssl-dev pkg-config这里提醒一个细节如果你的系统比较老比如CentOS 7自带的cmake可能才3.x早期版本不满足MySQL 8.0的要求。很大概率需要先升级cmake从源码编译一个较新的cmake或者用pip安装的cmake实际是二进制轮子。我之前在CentOS 7上编译8.0.36就先把cmake从3.17换成了3.25不然配置阶段直接报版本过低。如果你要编译的是5.7这种老版本在CentOS 8/Rocky 9上还会遇到rpc/types.h找不到的毛病这是系统移除了老rpc库导致的一般装上rpcsvc-proto-devel就能解决yum install -y rpcsvc-proto-devel这个坑我踩过两次每次报错都一模一样不看系统版本很容易当灵异事件处理。2.2 版本选择与源码获取确定版本前先说一下版本背景。MySQL 5.7这一系列在2023年10月以5.7.44收尾并停止官方更新之后社区安全维护基本靠各发行版和第三方接手。8.0是时间最长的LTS系列目前仍在持续迭代适合绝大多数生产环境。还有新的9.x等版本但新版本特性激进、生态沉淀不如8.0生产选型我一般不建议一上来就用最新。源码获取有两个途径官方MySQL Archives页面以及GitHub的mysql/mysql-server仓库。生产环境建议从官方下载对应版本的源码tar包因为打了官方tag完整性有保障。GitHub仓库适合想基于最新代码做二次开发的朋友。wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.46.tar.gz tar -xzf mysql-8.0.46.tar.gz cd mysql-8.0.46这里有个经验源码包的体积不算大解压后大约2~3GB但编译会产生大量中间文件所以工作目录所在磁盘至少要预留25GB空间。我之前有一台测试机/tmp挂在了一个10GB的小分区上编译到一半直接把分区撑爆了报错还是看不懂的No space left on device排查了半天才发现是临时目录的问题。如果网络环境不好可以用-DDOWNLOAD_BOOST1让CMake在配置阶段自动下载Boost这个话题下面会详细讲。2.3 Boost依赖的获取MySQL 8.0的源码编译依赖Boost库这是很多人第一次编译时最容易卡住的地方。官方文档明确要求特定版本的Boost不同小版本对应的Boost版本还不一样比如8.0.27之前常用1.73.0后续版本又要求1.77.0之类。手动去Boost官网找对应版本再解压、配置路径整个过程比较繁琐。最省事的做法是让CMake自动下载配置时指定WITH_BOOST目录同时加上DOWNLOAD_BOOST1CMake会检测本地没有对应版本后自动从Boost官网下载并解压。mkdir -p /opt/mysql-deps后面在cmake配置阶段加这两个参数-DWITH_BOOST/opt/mysql-deps/boost -DDOWNLOAD_BOOST1第一次执行cmake时会看到类似“Downloading Boost”的日志输出说明它正在干活。如果公司内网屏蔽了外网就得提前在能联网的机器上下载对应Boost压缩包放到那个目录里再关掉DOWNLOAD_BOOST参数。3. CMake配置与核心参数全解析3.1 MySQL为什么用CMake而不是传统configure用过其他开源项目的人可能会习惯性地想执行./configure但MySQL很早就改用CMake了。原因很简单MySQL代码规模大、跨平台场景多Windows、Linux、macOSCMake在依赖探测、生成器抽象、多架构支持上都比autotools那一套更好维护。对用户来说区别就是所有配置参数从--prefix这种风格变成了-DCMAKE_INSTALL_PREFIX这种风格。理解了这一点后面看各种-WITH、-DWITHOUT参数就不会觉得杂乱它们本质都是CMake的变量定义。3.2 核心参数逐条理解以8.0版本为例cmake配置阶段最常用的参数有这么几类路径类参数CMAKE_INSTALL_PREFIX安装根目录默认是/usr/local/mysql二进制会装到bin、lib、share等同名子目录.MYSQL_DATADIR数据目录默认是/var/lib/mysql生产环境基本都会改到独立数据盘。SYSCONFDIR配置文件目录默认是/etc。存储引擎类参数WITH_INNOBASE_STORAGE_ENGINE启用InnoDB默认就是启用的WITHOUT_ARCHIVE_STORAGE_ENGINE、WITHOUT_BLACKHOLE_STORAGE_ENGINE等显式禁掉不需要的引擎可以减小体积和编译时间。字符集类参数DEFAULT_CHARSET默认字符集建议设为utf8mb4DEFAULT_COLLATION默认排序规则8.0建议utf8mb4_0900_ai_ci5.7建议utf8mb4_general_ciSSL类参数WITH_SSL可以设system或bundled。system表示用系统OpenSSLbundled表示用MySQL自带的分支。这里建议一开始就用system但要确保系统OpenSSL版本足够新不然会有一堆编译期报错后文有专项排查。构建类型参数CMAKE_BUILD_TYPEDebug、Release、RelWithDebInfo。生产环境用RelWithDebInfo最多既有优化又保留调试符号追求极致性能可以Release。Boost参数上面已经写过不再重复。3.3 一次完整的cmake配置案例下面是我最近在CentOS 7.9上编译MySQL 8.0.46实际用过的配置你可以直接作为模板cd mysql-8.0.46 cmake . \ -DCMAKE_INSTALL_PREFIX/usr/local/mysql \ -DMYSQL_DATADIR/data/mysql \ -DSYSCONFDIR/etc \ -DWITH_BOOST/opt/mysql-deps/boost \ -DDOWNLOAD_BOOST1 \ -DDEFAULT_CHARSETutf8mb4 \ -DDEFAULT_COLLATIONutf8mb4_0900_ai_ci \ -DWITH_SSLsystem \ -DWITH_INNOBASE_STORAGE_ENGINE1 \ -DWITHOUT_ARCHIVE_STORAGE_ENGINE1 \ -DWITHOUT_BLACKHOLE_STORAGE_ENGINE1 \ -DCMAKE_BUILD_TYPERelWithDebInfo配置成功的标志是最后出现一堆CMake生成的配置总结包括安装路径、支持的功能特性、编译的存储引擎列表。这个过程一般会持续几分钟因为CMake要做大量检测。如果配置不成功CMake会在末尾明显标注Error或者missing依赖。我的经验是先别急着Google把报错信息往上翻看它到底检测了什么失败多数问题都出在依赖库没装全。看到“CMake Error at cmake/boost.cmake”就知道是Boost问题看到“Could NOT find Curses”就知道是缺ncurses开发包信息其实都很直白。4. 编译、安装与初始化启动4.1 make编译与资源控制CMake配置通过后就进入真正的编译阶段。直接执行make会使用单进程速度很慢强烈建议开并行编译make -j$(nproc)这里的-j参数表示并行任务数$(nproc)会自动拿到CPU核心数。举例来说8核机器上就用make -j816核就用make -j16。但这里要特别提醒并行编译数是CPU核心数不是内存友好配置。MySQL 8.0全套编译非常吃内存我实测在4GB内存的机器上开-j8编译大概10分钟就出现OOM或者编译进程被kill的现象。合理的安全配方是内存8GB以下建议-j2或者-j4内存8GB~16GB可以-j4~j6内存16GB以上放心用-j8或更高如果机器内存紧张可以先扩大swap再编译比如临时创建一个swap文件编译完再释放。这个方法我多次用过能救急。整个编译过程耗时因机器而异8核8GB内存的机器编译8.0.46全套大概需要40分钟到1小时。期间日志滚屏很快不用盯着看偶尔瞄一眼有没有error即可。如果中途失败也不需要从零再来make会从断点继续大部分增量还会被复用。4.2 make install与安装目录结构编译通过后执行安装make install默认会安装到CMAKE_INSTALL_PREFIX指定的目录也就是前面配置的/usr/local/mysql。安装完成后可以看一眼目录结构ls -l /usr/local/mysql正常情况下会看到bin、lib、include、share、support-files等目录。bin下面有mysqld、mysql、mysqld_safe等关键文件。lib下面有libmysqlclient.so等客户端库。include下面是头文件供开发使用。得到一个自编译的MySQL后有件事容易忽略编译出来的mysqld默认可能依赖编译机上的动态库比如libssl.so、libcrypto.so。如果要部署到别的机器要么保证目标机器有相同版本动态库要么在编译时把相应库静态链进去或者干脆把依赖一起带上打包。这也是为什么很多人喜欢用Docker把编译好的MySQL装进镜像就是为了锁定运行环境。如果需要对编译结果做sanity check可以直接跑版本命令/usr/local/mysql/bin/mysqld --version输出类似“mysqld Ver 8.0.46 for Linux on x86_64 ...”就说明二进制基本可用。这里还能顺便验证你设置的构建类型和版本号。4.3 初始化数据目录并启动编译安装完的MySQL还需要初始化数据目录。8.0和5.7的做法类似都是使用mysqld --initialize。这里我习惯用--initialize-insecure因为这样root账号初期是空密码方便本地登录后再设置useradd -r -s /bin/false mysql mkdir -p /data/mysql chown -R mysql:mysql /data/mysql /usr/local/mysql/bin/mysqld \ --initialize-insecure \ --usermysql \ --basedir/usr/local/mysql \ --datadir/data/mysql初始化过程没有输出不代表失败退出码为0就成功了。如果有问题错误日志一般会写到数据目录下的.err文件或者终端直接打印。启动时最方便的是用mysqld_safe/usr/local/mysql/bin/mysqld_safe --usermysql 然后确认进程和端口mysqladmin -uroot ping mysql -uroot -e select version();如果要用systemd管理可以简单写一个service文件核心就是指定mysqld路径、--user和pid文件路径这里不展开。需要提醒的是如果你把数据目录放在/usr/local/mysql默认目录下chown到mysql用户这步一定不能省否则启动瞬间就会Permission denied。5. 编译踩坑实录常见错误与排查5.1 常见编译错误速查表源码编译最容易遇到的是各种“找不到库”和版本不匹配。我把实际遇到过、以及群里朋友反复问过的问题整理成了下面这个速查表排查时直接对照即可。报错关键字原因解决方案Could NOT find Curses缺少ncurses开发包安装ncurses-devel或libncurses-devCould not find BoostBoost缺失或版本不符安装对应Boost或加DOWNLOAD_BOOST1compiler not supportedGCC版本太低升级GCC到7.1或编译8.0时选老版本rpc/types.h: No such file老版本在新系统编译缺rpc库安装rpcsvc-proto-develNo space left on device磁盘空间不足或tmp分区过小预留25GB以上清理临时文件libssl.so.1.1 not found编译机OpenSSL版本和运行环境不一致统一动态库或用bundled方式编译DSO missing from command line链接顺序或库引用问题检查LDFLAGS和依赖库路径5.2 Boost、OpenSSL等第三方库冲突单独说Boost是因为它出现频率太高。如果你手动下载Boost版本不对的话哪个版本都不行比如8.0.46可能要求1.77.0你放了1.73.0CMake大概率还是报错。所以我在前面强调过优先用自动下载参数不要自己猜版本。自动下载虽然第一次慢但它会根据当前MySQL源码的校验和去匹配正确的Boost版本这个优点在多次重编译时特别明显。OpenSSL的坑则更多在编译成功后启动阶段暴露。比如你编译时用的WITH_SSLsystem编译机上的OpenSSL版本是1.1.1可部署机上只有3.0的动态库启动时就会报找不到libssl.so.1.1。解决思路要么是编译时直接用bundled方式让MySQL自带SSL实现要么就把部署机运维成本算上提前统一OpenSSL版本。我个人在交付自编译版本时如果客户对SSL版本没特殊要求一般倾向于WITH_SSLsystem并明确记录依赖库版本反而比bundled更容易维护。5.3 编译成功但起不来启动阶段的典型问题编译成功只是第一步我在现场排障中见过最多的问题是数据目录、权限、动态库三件套。先看日志。MySQL初始化或启动出错时错误会在错误日志里写得很清楚。8.0默认日志在数据目录下的主机名.err比如localhost.localdomain.err。很多时候看一眼日志前几行问题就定位了。典型报错之一[ERROR] Cant open the mysql.plugin table这个多发生在数据目录没有正确初始化或者使用了不匹配的初始化方式。解决就是删掉数据目录重新执行mysqld --initialize。典型报错之二[ERROR] Could not open required defaults file: /etc/my.cnf这是没找到配置文件。可以显式用--defaults-file指定配置文件路径或者在/etc下准备好my.cnf。典型报错之三[ERROR] /usr/local/mysql/bin/mysqld: Cant create/write to file /tmp/xxx.log这是/tmp权限或空间问题。可以临时把tmpdir指到别的目录比如/tmp改到/var/tmp或者在my.cnf里配置tmpdir。启动阶段还有一类常见问题是mysqld_safe找不到mysqld。如果你把二进制放在非默认路径最好显式指定/usr/local/mysql/bin/mysqld_safe --usermysql --ledir/usr/local/mysql/bin --ledir就是mysqld二进制所在目录老版本也叫--mysqld。6. 进阶按需求定制编译效果6.1 裁剪模块与体积控制自编译最爽的地方在于你可以按需裁剪。对大多数纯OLTP业务来说Archive、Blackhole、Federated这些引擎基本用不到禁掉它们之后编译时间、安装体积、可能会有微小的内存占用优化。裁剪方式就是前面提到的-DWITHOUT_ARCHIVE_STORAGE_ENGINE1 \ -DWITHOUT_BLACKHOLE_STORAGE_ENGINE1 \ -DWITHOUT_FEDERATED_STORAGE_ENGINE1还有两个值得注意的选项DWITH_UNIT_TESTS1和DWITHOUT_UNIT_TESTS。默认情况下8.0源码会编译一部分单元测试相关目标如果只是部署生产库不需要跑源码级测试建议显式加-DWITHOUT_UNIT_TESTS1缩短编译时间。另外如果你明确不打算用性能监控相关的某些插件也可以在配置阶段通过-DWITHOUT_xxx_PLUGIN关掉对应插件模块。不过插件裁剪的影响面比存储引擎大建议在测试环境验证后再上生产。6.2 编译优化选项与调试信息的取舍CMAKE_BUILD_TYPE是容易被忽略的关键开关。Debug构建会关闭大量优化便于GDB调试但性能远低于生产标准只适合开发调试内部逻辑。Release构建开启-O2级优化实际MySQL的cmake脚本会启用一些默认优化参数但崩了之后没有符号信息很难定位问题。RelWithDebInfo兼顾了两者生产环境最稳妥。如果对极致CPU指令集有要求也可以在CMAKE_C_FLAGS和CMAKE_CXX_FLAGS里追加-march等参数。举个实际例子-DCMAKE_C_FLAGS-O3 -marchnehalem \ -DCMAKE_CXX_FLAGS-O3 -marchnehalem不过这个操作风险也大一旦跑在比编译目标更老的CPU上会发生非法指令错误。所以除非你有非常明确的硬件清单否则我不建议随意加-marchO2/RelWithDebInfo的默认组合完全够用。最后说个我个人的习惯。每次编译前我会把cmake命令完整保存到一个build.sh脚本里随版本库或发版物料一起留存。这样别人拿到一个二进制包的时候还能清楚地知道它当时是怎么配置出来的。遇到诡异性能问题或兼容问题这份记录往往比代码注释还管用。编译不是玄学配置录得越完整后面的运维越省心。