确认是oom killer所致，执行dmesg -t | grep -i "killed process"查看含make/cc1plus/ld及时间匹配的日志；编译时应改用make -j1、-dcmake_build_type=release、预编译boost、启用ld.gold或--reduce-memory-overheads。
make 过程中因内存不足直接 Killed，不是 MySQL 自己报错，而是 Linux 内核的 oom-killer 杀掉了编译进程——你看到的终端输出只有 “Killed” 二字，make 就中断了，连错误行号都不会有。这种情况在 8.0 源码编译（尤其启用 -DWITH_SSL=system 或 -DWITH_BOOST）时极常见，本质是链接阶段（ld）或并行编译（-j）吃光内存。
确认是不是 oom-killer 干的
别猜，直接查系统日志。执行：dmesg -T | grep -i "killed process"
如果输出里带 make、cc1plus、ld 或时间戳和你编译中断时刻一致，就是它。
常见现象：
• 终端卡住几秒后突然退出，只显示 Killed
• free -h 显示可用内存 free 列接近 0，available 也低于 100MB
• ps aux --sort=-%mem 看不到正在跑的 make，但能看到残留的 cc1plus 或 ld 进程占满 RSS
编译时怎么压内存用量
MySQL 8.0 源码编译默认开很多并行、加载大量模板、链接静态库，每一步都吃内存。关键控制点如下：
- 禁用并行：把
make -j$(nproc)改成make -j1—— 单线程编译，内存峰值下降 60% 以上，只是慢一点 - 关掉调试符号：
-DCMAKE_BUILD_TYPE=RelWithDebInfo改成-DCMAKE_BUILD_TYPE=Release，避免g++生成巨量.debug_*段 - 跳过 Boost 编译：
-DWITH_BOOST=/path/to/boost必须指向预编译好的 Boost（如系统包libboost1.74-dev），否则cmake会自己下源码再编译一份，额外吃 2GB+ - 不编译测试套件：
-DENABLE_DOWNLOADS=OFF -DINSTALL_TESTDICT=OFF，省掉mysql-test目录的构建压力
链接阶段特别容易爆内存
MySQL 8.0 最后链接 mysqld 二进制时，ld 默认用 --no-as-needed 和大量静态库，导致内存暴涨。临时缓解方法：
- 换轻量链接器：
export LD=ld.gold（需先装binutils-gold），比ld.bfd内存效率高 30%～40% - 加链接参数：
-DCMAKE_EXE_LINKER_FLAGS="-Wl,--no-as-needed -Wl,--reduce-memory-overheads" - 物理内存确实紧张时，强制启用 Swap：
sudo swapon /swapfile（哪怕只有 1GB，也能让ld活下来）
注意：--reduce-memory-overheads 在较新 binutils 中才支持，CentOS 7 默认不带，得升级或换 Ubuntu 22.04+。
为什么不是调大 innodb_buffer_pool_size
这个问题常被误判成“MySQL 配置问题”，但源码编译阶段 mysqld 根本没启动，innodb_buffer_pool_size 完全不生效。所有运行时参数（sort_buffer_size、tmp_table_size 等）此时都无关——你是在构建可执行文件，不是在跑数据库。
真正要盯的是编译环境本身：可用内存是否 ≥4GB（最低要求）、Swap 是否就位、cc1plus 进程 RSS 是否超限、ld 是否被 oom-killer 锁定为目标。一旦 dmesg 确认是 oom-killer，就别碰 my.cnf，直接切回编译命令调参。
