这不是 mysql 本身的问题，而是系统 glibc 版本过低（如 centos 6 的 2.12）不满足 mysql 8.0+ 所需的 glibc_2.14；严禁手动升级 glibc，应改用官方 yum/apt 源安装、降级 mysql 版本或使用 docker 容器。
MySQL 安装报错 GLIBC_2.14 not found 怎么办
直接说结论：这不是 MySQL 本身的问题，而是你系统自带的 glibc 版本太老（比如 CentOS 6 默认是 glibc-2.12），而官方 MySQL 8.0+ 二进制包编译时依赖 GLIBC_2.14 或更高。强行升级 glibc 极其危险，会导致系统崩溃——别试。
用官方推荐的替代方案：改用 YUM/Apt 源安装或降级 MySQL 版本
MySQL 官方明确不建议用户手动替换 glibc，而是提供兼容旧系统的安装方式：
- CentOS/RHEL 6/7：从 MySQL Yum Repository 安装，它会自动适配系统
glibc，例如mysql80-community-release-el6-3.noarch.rpm就是为 EL6 编译的 - Ubuntu 16.04（
glibc-2.23）可装 MySQL 8.0；但 Ubuntu 14.04（glibc-2.19）只能装 MySQL 5.7 —— 查看你的lsb_release -a和ldd --version再选版本 - 若必须用 MySQL 8.0 且系统无法升级，考虑 Docker：
docker run -d --name mysql8 -e MYSQL_ROOT_PASSWORD=123 -p 3306:3306 mysql:8.0，容器内自带完整运行时，不依赖宿主机glibc
自己编译 MySQL 真的能绕过 GLIBC 限制？
理论上可以，但实际代价远超收益：
- 必须用目标系统上已有的
glibc头文件和库来编译（例如在 CentOS 6 上用gcc+glibc-devel-2.12），否则链接阶段就失败 - MySQL 8.0 的 CMake 配置项
-DWITH_SSL=system和-DWITH_ZLIB=system必须显式指定，否则可能悄悄拉入高版本依赖 - 编译耗时长（30+ 分钟），且后续升级、打补丁、调试都得自己维护，CI/CD 流水线也得同步改造
- MySQL 官方不测试、不支持非标准编译产物，出问题只能自己 debug
升级系统内核 ≠ 升级 glibc，别混淆
很多人误以为“升级内核就能解决 GLIBC 问题”，这是典型概念错位：
-
glibc是用户空间 C 标准库，和内核（kernel）完全独立；升级kernel-3.10到kernel-5.15不会改变glibc版本 - 真正升级
glibc只有换发行版大版本（如 CentOS 6 → CentOS 7）或重装系统；小版本更新（如glibc-2.12-1.212→glibc-2.12-1.222）只是安全补丁，不新增符号 - 某些云厂商提供的“CentOS 6 兼容版 MySQL 8.0”其实是静态链接或 musl 替代方案，不是靠升级
glibc
最稳妥的路径永远是：查清当前 glibc 版本 → 对照 MySQL 官方二进制兼容表 → 选对源或容器镜像。硬刚 glibc 的人，最后基本都重装了系统。
