我做了三年多MySQL运维源码编译安装的次数两只手数不过来。每次有人问我MySQL怎么装我都会反问一句你是要用还是要去研究它用的话直接下二进制包研究它或者对性能有执念才需要考虑源码编译。而源码编译这件事真正核心的部分就是那一长串cmake参数。很多时候你在网上搜到一篇编译教程复制粘贴了一段cmake命令装也装上了跑也跑起来了但你根本不知道那几十个-D参数到底干了什么。等某天你发现数据目录不在预期位置、字符集默认不是utf8mb4、或者想用某个插件却编不进去再回去看编译参数才意识到当初偷的懒全要还。这篇文章把我这些年用过的、踩过的MySQL编译参数全部梳理一遍讲清楚每个参数解决什么问题、该怎么选、有哪些坑最后给出生产环境和开发环境的完整参考命令。1. MySQL源码编译的基本盘1.1 为什么源码编译依然有存在的必要先说结论90%的场景不需要源码编译用官方二进制包或者系统包管理器装就行。但剩下10%的场景源码编译是唯一的路。第一种场景是定制化需求。比如你想把默认字符集写死成utf8mb4、默认存储引擎写死成InnoDB又不想在my.cnf里靠后置配置去覆盖那编译期参数就是最干净的方案。编译参数决定的是基因my.cnf决定的是后天的行为。基因层面的东西后期改起来很别扭。第二种场景是平台适配。某些国产化环境、特殊内核、精简系统二进制包可能跟你那套底层库对不上openssl版本、glibc版本、libaio有没有编进去都会成为压死骆驼的最后一根稻草。源码编译至少能保证我把依赖都打进去了。第三种场景是性能洁癖。官方二进制包为了兼容性编译时用的是通用指令集没有针对你的CPU做特定优化。自己编可以在CFLAGS里开-march、-mtune这类指令集优化压榨出那百分之几的性能。做高并发数据库的这几百分点有时候就是生死线。接下来是理解源码编译的关键MySQL从5.7版本开始全面转向CMake构建体系不再使用老的configure脚本。所以你看到的编译命令统统是cmake .. -Dxxxyyy这种形式。这套构建体系最大的特点是参数一旦在编译期确定会直接写死在二进制和内部默认配置里这不是改个配置文件就能覆盖的。1.2 编译参数决定MySQL的基因我一直跟团队说一句话my.cnf是后天养成编译参数是先天的基因组。为什么这么说因为以下几个核心行为编译期就定死了。数据目录的默认位置、配置文件的默认搜索路径、默认端口和socket文件位置这些都是编译参数决定的。你装完之后不写my.cnf直接启动它找哪个路径、用哪个目录全部是编译期就固化好的默认值。字符集和排序规则更是如此。编译期指定了utf8mb4和utf8mb4_general_ci那这个MySQL实例的默认字符集就是这个建库建表不指定字符集时全部按这个默认值走。后期想在所有库表上改字符集那是一场旷日持久的ALTER TABLE迁移。存储引擎也一样。虽然MySQL支持运行时INSTALL PLUGIN加载引擎但核心的InnoDB、MyISAM如果在编译期没有编进去后期你连加载的入口都找不到。这也是为什么编译之前一定要想清楚我要跑什么样的业务。还有一个容易被忽略的点编译时有没有带WITH_DEBUG直接决定这个二进制能不能用debug模式跑。生产环境当然不会编debug版本但你调试插件或者看核心转储的时候没有debug信息够你喝一壶的。1.3 编译前先把依赖补齐我见过太多人cmake报错第一反应是这软件真难装其实八成是系统的编译工具链和依赖没装全。在Linux上编译MySQL以下这些是硬性条件。编译器gcc/g建议版本不低于gcc 7.5编译MySQL 8.0建议用gcc 11以上否则会遇到C17标准适配问题构建工具cmake 3.x8.0版本要求cmake 3.7以上越新越好ncurses-devel终端交互界面没有它cmake直接报错bison语法解析器生成工具MySQL解析SQL语法需要它openssl-devel编译SSL支持时的必备依赖libaio-develAIO异步I/O库InnoDB的native AIO需要numactl-devel如果要启用NUMA感知pkg-config用来发现各种依赖库的路径以CentOS/RHEL系为例一条命令装齐大部分依赖yum install -y gcc gcc-c cmake ncurses-devel bison openssl-devel libaio-devel numactl-devel pkgconfig make perlUbuntu/Debian系则是apt-get install -y build-essential cmake libncurses5-dev libncursesw5-dev bison libssl-dev libaio-dev libnuma-dev pkg-config这里我特别提醒一点8.0版本还需要libtinfo、zlib等依赖而且不同小版本对依赖版本的要求有微妙差异。所以最稳妥的办法是先看官方文档中该版本的System Requirements再结合报错逐个补包。2. 核心编译参数逐个拆解2.1 路径三件套安装目录、数据目录、配置目录MySQL编译参数里最核心、最影响日常使用的就是三个路径参数。-DCMAKE_INSTALL_PREFIX/usr/local/mysql -DMYSQL_DATADIR/data/mysql -DSYSCONFDIR/etcCMAKE_INSTALL_PREFIX是安装根目录所有二进制、库文件、头文件、man文档都会按约定布局安装到这个目录下面。官方默认值是/usr/local/mysql。很多人图省事不指定结果装到了默认路径等要升级或者迁移的时候才发现目录规划一塌糊涂。我的习惯是显式指定同时跟公司的服务器目录规范对齐。MYSQL_DATADIR是数据目录的默认路径。注意这个参数更多是给mysql_install_db或者mysqld --initialize做默认参考使用的真正的数据目录你在启动参数--datadir或者my.cnf里也能覆盖。但编译期写死的好处是你没配任何东西的时候它不会跑到错误的地方去。SYSCONFDIR是配置文件搜索路径。MySQL启动时按照固定的顺序去搜my.cnf/etc/my.cnf是默认兜底路径。这个参数一般不用改除非你的系统规范要求配置目录放在别的地方比如某些云镜像把配置集中到/etc/mysql/下。我踩过的坑是当时图省事没有指定MYSQL_DATADIR编译完直接mysqld --initialize结果数据初始化到了默认的/usr/local/mysql/data。因为当时那个分区只有20G数据库跑了半年把根分区撑爆了迁移数据的时候才叫痛苦。所以路径规划这种事编译之前就要想清楚。2.2 字符集和排序规则这个参数选错后面全是泪字符集相关的参数有三个组合起来决定MySQL的文本处理基因。-DDEFAULT_CHARSETutf8mb4 -DDEFAULT_COLLATIONutf8mb4_general_ci -DWITH_EXTRA_CHARSETSallDEFAULT_CHARSET是默认字符集DEFAULT_COLLATION是默认排序规则WITH_EXTRA_CHARSETS决定额外编入哪些字符集。先说字符集的选择。老项目很多还在用utf8但MySQL里的utf8是个历史遗留坑它最多只能存3字节的UTF-8字符。这意味着emoji、生僻汉字这些4字节字符在utf8字符集下根本存不进去报错长这样Incorrect string value: \xF0\x9F\x98\x80。而utf8mb4是真正的完整UTF-84字节支持兼容性更好。所以新项目我全部推荐utf8mb4如果你维护老库也建议逐步迁移。再讲排序规则。utf8mb4_general_ci是通用排序速度快但对某些语言字符排序不够精准utf8mb4_0900_ai_ci是MySQL 8.0之后默认的排序规则基于Unicode 9.0标准支持更准确的排序和重音、大小写不敏感匹配。我个人的选择是5.7用utf8mb4_general_ci8.0直接用默认的utf8mb4_0900_ai_ci不需要刻意改。因为8.0的默认排序规则在很多场景下已经足够好改回去反而是画蛇添足。WITH_EXTRA_CHARSETS这个参数我一般直接设all。MySQL的额外字符集包括gbk、gb2312、big5、latin1等等。虽然默认字符集是utf8mb4但保不齐哪天有个老系统导入数据要用gbk编译的时候就全编上成本几乎为零省得日后用INSTALL COMPRESSED_IMPORT一步的功夫都没有。2.3 存储引擎参数不是越多越好但关键的你得有存储引擎在MySQL里是插件化架构编译时通过-DWITH_xxx_STORAGE_ENGINE来控制。-DWITH_INNOBASE_STORAGE_ENGINE1 -DWITH_MYISAM_STORAGE_ENGINE1 -DWITH_ARCHIVE_STORAGE_ENGINE1 -DWITH_BLACKHOLE_STORAGE_ENGINE1 -DWITH_FEDERATED_STORAGE_ENGINE1 -DWITH_PARTITION_STORAGE_ENGINE1MySQL 5.7之后InnoDB、MyISAM、MERGE、MEMORY这几个引擎默认就编进核心了不需要额外指定。需要显式打开的主要是ARCHIVE归档存储适合日志类冷数据、BLACKHOLE黑洞引擎写入即丢弃常用于复制中继或者审计场景、FEDERATED联邦引擎可以访问远程MySQL表。PARTITION_STORAGE_ENGINE在5.7之前需要显式开启5.7开始分区支持是内置的不需要额外配置。但如果你还在维护5.6的老环境记得把这个参数加上否则PARTITION BY语法会报错。我的习惯是InnoDB和MyISAM必须ARCHIVE顺手就开BLACKHOLE在需要做主从复制的过滤场景有用FEDERATED虽然鸡肋但留着以备不时之需。多编两个引擎不影响主流程性能主要就是二进制大一点。真正要注意的是别去开那些你用不上的引擎编译时间和后期插件包体积都会有负担。关于引擎还有一层关系要想清楚MySQL 8.0已经把MyISAM全部移出系统表数据字典统一由InnoDB管理。这意味着8.0环境下MyISAM已经变成一个边缘引擎日常业务表就别再用它了只留它在系统里做兼容就行。2.4 端口、socket、本地文件导入这些运行参数除了路径和字符集还有几个日常运行相关的参数也经常在编译时指定。-DMYSQL_TCP_PORT3306 -DMYSQL_UNIX_ADDR/tmp/mysql.sock -DENABLED_LOCAL_INFILE1MYSQL_TCP_PORT是默认TCP监听端口MYSQL_UNIX_ADDR是socket文件默认位置。这两个参数在my.cnf里也能配但编译期写死的好处是当你的my.cnf被搞坏或者临时用一个极简配置启动时至少端口和socket不会错。ENABLED_LOCAL_INFILE这个参数值得单独说。它控制LOAD DATA LOCAL INFILE语法是否可用。这个功能允许客户端把本地文件加载到数据库服务端。这个功能有安全风险如果客户端被诱导可能读取客户端机器上的任意文件传给服务器。所以MySQL默认是关闭的需要在编译期显式开启配合my.cnf里的local-infile1才能完全生效。我的建议是内网环境上下游数据交换频繁的场景编进去否则后面导入CSV数据的时候天天跟权限较劲公网环境或者安全性要求极高的场景保持默认关闭就是对的需要用的时候临时改配置再重启也来得及。3. 那些要额外小心的编译参数3.1 Boost依赖这个不解决连cmake都过不去MySQL 5.7.6开始源码包不再自带Boost库编译时必须指定Boost 1.59.0不同版本要求不同8.0要求1.77.0以上否则cmake直接报错Could NOT find Boost。这也是源码编译报错率最高的地方。解决方式有两种第一种是手动下载Boost并指定路径-DWITH_BOOST/usr/local/boost_1_59_0第二种是让cmake自动下载-DDOWNLOAD_BOOST1我建议官网源码编译用DOWNLOAD_BOOST1省去手动下载和版本不匹配的烦恼。但要注意这个下载走的是外网如果网络环境受限一直卡在下载阶段那你得手动下载包放到本地再指向路径。这里有个细节如果你手动下载一定要确认Boost版本和MySQL版本匹配5.7.44要求Boost 1.59.08.0.36要求Boost 1.77.0版本对不上编译照样失败。3.2 SSL/TLS参数openssl版本匹配的坑MySQL支持在编译期启用SSL参数是-DWITH_SSLsystem或者-DWITH_SSL/path/to/openssl。system表示使用系统自带的OpenSSL库优点是不用额外编译openssl缺点是版本由系统决定CentOS 7自带的OpenSSL 1.0.2已经太老有些加密套件新客户端不认。另一个选择是指定一个自己编译的高版本OpenSSL比如1.1.1或者3.x。我碰到的真实案例是编译时用了system系统里是OpenSSL 1.0.2某个新版本的MySQL客户端连上来之后报告SSL握手失败因为加密套件不匹配。日志报错看似复杂其实根源就是服务端OpenSSL太旧支持的套件列表跟客户端没有交集。最后重新编译MySQL把WITH_SSL指向1.1.1版本的OpenSSL问题解决。实际操作中还有个问题 openssl不是你想编就能编进去的它要求开发头文件存在。所以编译之前先检查一下openssl version再确认/usr/include/openssl/ssl.h在不在缺了就装openssl-devel。如果系统openssl版本实在太旧就自己做一个新版出来./config --prefix/usr/local/openssl shared make -j$(nproc) make install然后再编译MySQL时指定这个路径。3.3 systemd、readline和其他系统集成参数MySQL 5.7及之后版本官方增加了对systemd的支持参数。-DWITH_SYSTEMD1这个参数会让MySQL安装自带systemd的unit文件mysqld可以通过systemctl start mysqld管理。如果不开你得自己写init脚本或者手动启停日常运维体验差不少。我的建议是服务器是systemd系CentOS 7、Ubuntu 16.04就一定要开。-DWITH_READLINE1这个参数控制MySQL命令行客户端是否支持方向键、历史命令回调这些交互功能。如果你不编进去mysql客户端用起来方向键乱码想调出历史命令都不行就是在裸奔。MySQL 8.0之后这个参数已经默认开启不需要特意指定但编译5.7的时候还是建议显式加上。还有一个容易忽略的是-DWITH_ZLIBbundled。这个决定MySQL内部是否使用自带zlib做压缩支持。官方一般默认用系统zlib但有些精简系统zlib版本过老会导致备份工具压缩输出损坏。用bundled虽然二进制会大一点但能保证压缩行为一致性不会莫名其妙报zlib版本问题。3.4 调试和性能相关的编译选项如果你要拿MySQL做二次开发或者深入学习内核那-DCMAKE_BUILD_TYPEDebug或者-DWITH_DEBUG1要打开。debug版本会保留符号表、关闭编译优化gdb跟踪的时候能直接看到函数名和行号。代价就是性能下降很多二进制也大好几倍生产环境绝对不能用。生产环境则建议-DCMAKE_BUILD_TYPERelease默认启用O2级别的编译器优化。如果想要更激进的优化可以追加-DCMAKE_C_FLAGS-O3 -marchnative -DCMAKE_CXX_FLAGS-O3 -marchnative-marchnative的意思是让gcc针对你的CPU型号自动生成指令集能榨出原生性能。但我必须提醒一句这个优化只对当前机器有效编译完的二进制拿到别的机器上跑极可能直接illegal instruction崩掉。如果你有服务器集群且硬件型号不统一别用-marchnative退而求其次用-mtunegeneric。-DWITH_NUMA1这个参数我单独拿出来说。它决定mysqld启动时是否自动遵循NUMA内存分配策略。对于大内存服务器通常128G以上开了NUMA可以让内存分配更均匀避免访问远端内存导致性能损耗。但要注意编译期开了NUMA启动时还需要配合innodb_numa_interleaveON才能真正生效。如果你的服务器内存不大没必要开。还有两个插件参数经常被问-DWITH_ICU和-DWITH_PROTOBUF。前者是国际化组件MySQL 8.0的排序规则依赖它编进去是必须的。后者是序列化协议库MySQL 8.0用来做X Protocol和内部RPC也是必须的。但这两个参数你基本不用手动指定cmake会自动检测除非你的系统库版本太旧导致检测失败。我之前遇到过Ubuntu 18.04上protobuf版本过旧MySQL 8.0.28编译直接报错最后是手动指定了更高版本的protobuf路径解决的。4. 实战从编译到启动的一整套组合4.1 生产环境参考命令下面这个组合是我在多个线上环境验证过的适合CentOS 7/RHEL系、MySQL 5.7.44对InnoDB主从、大数据量导入、常规OLTP业务都友好cmake .. \ -DCMAKE_INSTALL_PREFIX/usr/local/mysql \ -DMYSQL_DATADIR/data/mysql \ -DSYSCONFDIR/etc \ -DDEFAULT_CHARSETutf8mb4 \ -DDEFAULT_COLLATIONutf8mb4_general_ci \ -DWITH_EXTRA_CHARSETSall \ -DWITH_INNOBASE_STORAGE_ENGINE1 \ -DWITH_MYISAM_STORAGE_ENGINE1 \ -DWITH_ARCHIVE_STORAGE_ENGINE1 \ -DWITH_BLACKHOLE_STORAGE_ENGINE1 \ -DWITH_FEDERATED_STORAGE_ENGINE1 \ -DMYSQL_TCP_PORT3306 \ -DMYSQL_UNIX_ADDR/tmp/mysql.sock \ -DENABLED_LOCAL_INFILE1 \ -DWITH_BOOST/usr/local/boost_1_59_0 \ -DWITH_SSLsystem \ -DWITH_READLINE1 \ -DWITH_SYSTEMD1 \ -DWITH_ZLIBbundled \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_C_FLAGS-O3 \ -DCMAKE_CXX_FLAGS-O3如果你是MySQL 8.0改动主要有三点Boost版本换成对应版本比如1.77.0排序规则直接用utf8mb4_0900_ai_ci或者干脆去掉DEFAULT_COLLATION让它自动用默认值另外8.0默认已经包含某些引擎直接沿用上面的引擎配置没问题但要注意8.0的WITH_PARTITION_STORAGE_ENGINE已经不用了。4.2 开发调试环境精简方案开发机上我一般会砍掉SSL、NUMA这些跟业务关系不大的参数把-DWITH_DEBUG1打开方便gdb跟踪。而且开发机通常配置不高我会把Boost用自动下载方式省掉手动准备cmake .. \ -DCMAKE_INSTALL_PREFIX/usr/local/mysql-dev \ -DMYSQL_DATADIR/data/mysql-dev \ -DDEFAULT_CHARSETutf8mb4 \ -DDOWNLOAD_BOOST1 \ -DWITH_DEBUG1 \ -DWITH_SYSTEMD1 \ -DWITH_READLINE1 \ -DENABLED_LOCAL_INFILE1 \ -DCMAKE_BUILD_TYPEDebug这里重点是DOWNLOAD_BOOST1确实省事。DEBUG模式我第一次编的时候没意识到它有多慢一个8.0版本编了将近两个小时比Release版慢一倍还多。所以开发机编debug版本make -j$(nproc)也可以但有个心理准备就行。4.3 不同版本之间的参数差异我用一张表来总结5.7和8.0的编译参数差异参数MySQL 5.7MySQL 8.0说明Boost-DWITH_BOOST-DWITH_BOOST8.0要求更高版本Partition引擎-DWITH_PARTITION_STORAGE_ENGINE不需要8.0内置分区支持默认排序规则自动utf8mb4_0900_ai_ci8.0对unicode支持更强WITH_ICU可选必须8.0排序规则依赖ICUWITH_PROTOBUF不需要必须8.0内部RPC/XProtocol依赖WITH_SYSTEMD可选推荐8.0更完善版本差异里最坑的就是Boost版本。MySQL 5.7只要1.59.08.0要1.77.0如果你在网上随便下载了一个Boost版本对不上就会在cmake阶段报错而且是那种看了半天的C compiler cannot create executables这类误导性报错实际指向的却是Boost版本不对。5. 编译过程中绕不开的坑5.1 依赖缺失导致的cMake地狱编译MySQL最常见的报错是依赖缺失最典型的是Could NOT find Curses。这个报错的意思是系统没有ncurses开发库你yum install ncurses-devel或者apt-get install libncurses-dev装了就过。偏偏很多人卡在这里反复重试以为源代码有问题。另一个典型报错是Could NOT find OpenSSL。这个报错通常不是真的没装openssl而是没装开发头文件openssl-devel。Linux系统很多东西运行库和开发库是分开的运行库已经有了开发头文件还在云里。敲一下ls /usr/include/openssl/ssl.h没有就补装。解决依赖问题我的策略从来不是一个个去搜报错而是先看官方文档列出的依赖清单然后比对操作系统的包管理列表。yum list installed | grep devel、dpkg -l | grep dev一行命令把缺的包补齐往往比反复重试cmake高效得多。5.2 Boost下载失败和版本不匹配Boost相关的坑我在3.1里说过一部分这里补充几个实战经验。如果你用了-DDOWNLOAD_BOOST1cmake会尝试从sourceforge或者其他镜像下载Boost。这个过程经常因为网络问题超时失败。遇到卡在下载的我推荐直接下载Boost源码包放到本地然后指向WITH_BOOST路径。这里有个小细节Boost源码下载的是一个tar.gz包你需要先解压cmake找的是解压后的目录。我见过有人直接把tar包路径填进WITH_BOOST的结果cmake报了Boost not found in the given path。记住路径要指向解压后的目录我就是那个踩过坑的人。还有Boost版本匹配的问题。MySQL官方对每个版本要求的Boost版本是固定的你可以在源码包根目录的CMakeLists.txt或者官方编译文档里查到准确版本。不同小版本要求基本相同但大版本之间差异极大。5.7和8.0的Boost版本完全不同千万别混用。5.3 编译完之后启动失败编译只是第一步编译完启动才是真正验证参数是否正确的时候。我遇到过几次编译很顺利结果启动时各种闹心。最典型的是报错Cant find messagefile: /usr/local/mysql/share/errmsg.sys。这个报错通常是因为CMAKE_INSTALL_PREFIX路径跟实际路径不一致导致mysql找不到错误信息文件。解决办法就是把它指向正确的安装目录。另一个启动时报[ERROR] Cant open the mysql.plugin table大概率是你数据目录下还没有初始化系统表。源码编译之后5.7需要用mysqld --initialize来初始化数据目录8.0也是一样。很多人忘了这一步直接启动就报错。这里特别提醒初始化之前先建好MYSQL_DATADIR指向的目录并用chown mysql:mysql或编译时用户的属主改好权限。还有一类是权限问题。编译时如果用了root用户安装完的目录属主是root而mysqld要求以非root用户运行默认以mysql用户就会报Fatal error: Please read Security section of the manual to find out how to run mysqld as root!。解决办法是创建mysql用户并改属主useradd -r -s /sbin/nologin mysql chown -R mysql:mysql /usr/local/mysql /data/mysql5.4 编译完成后如何验证参数是否生效装了这么多参数怎么确认它们真的生效了不要靠猜要去看。先看编译产物里的默认值/usr/local/mysql/bin/mysqld --verbose --help | grep -E character-set-server|collation-server|datadir|port如果输出里字符集是utf8mb4、数据目录是/data/mysql说明编译参数生效了。再看更硬的证据——编译信息文件。MySQL源码编译后会在安装目录下生成一个mysql_config脚本/usr/local/mysql/bin/mysql_config它会把编译时的参数、库路径、头文件路径全部列出来。想看具体的编译选项还可以直接查看二进制的编译标志strings /usr/local/mysql/bin/mysqld | grep -i CMAKE_INSTALL_PREFIX这个方式能直接看到编译期固化的路径基本不存在my.cnf覆盖了默认值所以搞混了的问题。还有MySQL 8.0里有个更直接的变量SELECT version_compile_machine, version_compile_os, version_comment;能看出编译平台。虽然不直接显示参数但配合mysql_config基本能把家底翻个底朝天。6. 我对编译参数选择的一些真实体会编了这么多年我最大的体会是编译参数的选择本质是对你业务需求的一种提前规划。你不需要把所有参数都记住但你必须知道你配置的到底是什么。很多人嫌源码编译麻烦其实真正常遇到的问题就那么十几个花一天时间踩透一次后面所有环境都能举一反三。具体到参数取舍我最想强调的还是字符集、数据目录、SSL这三个点。字符集决定数据存储的编码基础改起来最伤筋动骨数据目录决定磁盘规划和未来扩容的路径改起来迁移成本极高SSL决定客户端连接的安全性基线混合客户端环境下最容易出兼容性问题。这三样定好其他参数都是可以后期通过配置调整的。另外分享一个小技巧每次编译前把完整的cmake命令存成一个shell脚本放在安装目录上级的build.sh里同时加上编译时间戳和MySQL版本注释。几个月后回来看你会庆幸当时的自己做了这件事。我现在基本不用去翻历史文档只要看某个MySQL实例的build.sh就知道它的基因是什么样的。MySQL源码编译这件事说穿了就是参数选择加依赖管理。参数选对了编译过程本身就变成了一件极其机械的事情。希望你读完这篇之后能在写下第一个-D参数的时候清楚地知道它背后改变的是什么。