MySQL 5.7 启动报 GLIBC_2.17 not found，是因为其二进制包（即使标称glibc2.12）实际链接了GLIBC_2.17符号，而CentOS 6等旧系统libc仅支持至GLIBC_2.12；正确解法是选用真正兼容的glibc2.12版MySQL包、Docker容器或源码编译，严禁手动升级glibc。
为什么 mysqld 启动报 GLIBC_2.17 not found
因为 MySQL 5.7 的二进制包（如 mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz）虽标称“glibc2.12”，但实际编译时仍可能链接了更高版本的符号——尤其是从 MySQL 官网下载的 5.7.30+ 版本，很多已悄悄依赖 GLIBC_2.17。系统运行 mysqld 时动态加载失败，就会卡在 /lib64/libc.so.6: version `GLIBC_2.17' not found。
如何准确查清系统和 MySQL 对应的 GLIBC 版本
别只看包名或文档描述，得实测：
- 查系统当前最低可用版本：
getconf GNU_LIBC_VERSION或ldd --version - 查 MySQL 二进制真正需要哪些符号：
objdump -T ./bin/mysqld | grep GLIBC_ | sort -u，重点关注输出里最高那个（比如GLIBC_2.17、GLIBC_2.18） - 确认是否真缺这个符号：
strings /lib64/libc.so.6 | grep GLIBC_2.17—— 若无输出，说明系统 libc 确实不提供该符号
用错 RPM 包是常见误操作点
CentOS 6 用户直接 yum install mysql-community-server-5.7.22-1.el7.x86_64 必然失败，错误信息里会明确出现：
Requires: libc.so.6(GLIBC_2.17)(64bit)-
Requires: systemd（CentOS 6 没 systemd） -
Requires: libsasl2.so.3（系统自带的是libsasl2.so.2）
根本原因是用了 el7 源而非 el6 源。正确做法是下载 mysql57-community-release-el6-1.noarch.rpm，再 yum install。
硬升级系统 glibc 是高危操作
有人想通过编译安装 glibc-2.14 或更高版来“匹配” MySQL，这非常危险：
-
glibc是系统底层运行时核心，升级失败会导致bash、ls、ssh全部失效 - 即使成功，也可能破坏
yum、systemd（如果存在）、甚至内核模块加载逻辑 - CentOS/RHEL 官方明确禁止用户手动升级 glibc
真正安全的解法只有三个：换用 glibc2.12 专用二进制包（如 mysql-5.7.39-linux-glibc2.12-x86_64.tar.gz）、改用 Docker 容器（如 mysql:5.7.42）、或源码编译（可控依赖版本）。
