启动mysqld报该错，根本原因是系统级动态链接器/lib64/ld-linux-x86-64.so.2缺失、损坏或权限错误，导致内核无法加载mysqld；它不是mysql文件问题，而是glibc运行时环境崩溃，需优先验证该文件存在性、可执行性及软链有效性，严禁强制重装glibc。
为什么启动 mysqld 会报 /lib64/ld-linux-x86-64.so.2: No such file or directory
这不是 MySQL 自身缺失文件，而是系统动态链接器被破坏或路径错位。该文件是 Linux x86_64 程序运行时必须加载的解释器（ELF interpreter），mysqld 启动前内核就要用它来加载依赖库。一旦它不存在、权限不对、或被误删/覆盖，所有依赖它的二进制程序（包括 ls、bash）都会直接失败。
检查 /lib64/ld-linux-x86-64.so.2 是否真实存在且可用
执行以下命令快速验证：
ls -l /lib64/ld-linux-x86-64.so.2
常见结果及对应操作：
- 文件不存在 → 很可能是
glibc包被强制卸载或损坏，不能靠单独下载 so 文件修复，需重装完整glibc包（但风险极高，见下一条） - 文件存在但权限非可执行（如无
x）→ 运行sudo chmod +x /lib64/ld-linux-x86-64.so.2 - 文件存在但指向一个坏软链（
ls -l显示-> ?或目标不存在）→ 用readlink -f /lib64/ld-linux-x86-64.so.2查真实路径，再确认目标是否存在 - 文件存在且权限正常，但
cd都报同样错 → 说明整个glibc运行时环境已崩溃，bash本身也依赖它，此时系统已不可信，应优先考虑从 Live CD 恢复或重装
不要手动替换或强制安装 glibc 相关包
这是最危险的操作，也是多数人把系统搞崩的直接原因。因为：
-
glibc是几乎所有用户态程序的底层依赖，升级/降级/覆盖它会导致ssh、systemd、bash全部失效 -
rpm --force --nodeps或dpkg --force-all会绕过所有依赖检查，极易留下不兼容的符号版本（如GLIBC_2.17被替换成2.12） - 你看到的
ld-linux-x86-64.so.2只是入口，背后还有一整套libc.so.6、libpthread.so.0等协同工作，单点修补必出问题
真正安全的做法是：确认当前系统发行版和 glibc 版本（ldd --version），然后下载**匹配该 glibc 版本**的 MySQL 二进制包（例如 CentOS 7.9 用 glibc2.17 包，而非 glibc2.28）。
MySQL 安装包里的 glibc 版本怎么选才不踩坑
MySQL 官方提供的 .tar.gz 包名中明确标注了所需 glibc 版本，例如：
-
mysql-8.4.0-linux-glibc2.17-x86_64.tar.gz→ 要求系统glibc >= 2.17 -
mysql-8.2.0-linux-glibc2.12-x86_64.tar.gz→ 兼容更老系统（如 CentOS 6） -
mysql-8.4.9-linux-glibc2.28-x86_64.tar.gz→ 仅适用于较新发行版（如 Rocky 9 / Ubuntu 22.04+）
选错的后果不是“启动失败”，而是“启动前就卡死在动态链接阶段”——也就是你看到的 ld-linux-x86-64.so.2 报错。所以务必先查系统版本：cat /etc/os-release 和 ldd --version，再去 MySQL 官网下载页按 glibc 标签筛选。
真正麻烦的点从来不在 MySQL 本身，而在于你手头这台机器的 glibc 是不是那个“刚好能跑起来”的版本。换包比修库快，也比重装系统稳。
