检查缺失的依赖库报错信息
MySQL 启动失败或安装中断时，常见错误如
error while loading shared libraries: libaio.so.1: cannot open shared object file或
libnuma.so.1: cannot open shared object file，说明系统缺少运行时依赖。这类报错一定出现在
mysqld启动阶段或
rpm -ivh/
dpkg -i安装包过程中，不是配置文件或权限问题。
CentOS/RHEL 系统下补全基础依赖
MySQL 官方二进制包和 RPM 包默认依赖
libaio、
numactl和
openssl-libs。未安装会导致服务无法启动或初始化失败：
yum install -y libaio numactl openssl-libs（CentOS 7/8） 若使用 MySQL 8.0+ 且启用数据字典加密，还需
libcrypt.so.1→ 安装
libxcrypt-compat（RHEL 8+） RPM 安装前可用
rpm -qpR mysql-community-server-8.0.xx-1.el8.x86_64.rpm查看显式依赖项
Ubuntu/Debian 系统对应依赖包名差异
Debian 系统的包名与 RHEL 不同，直接按名搜索会找不到：
libaio1→ 对应 RHEL 的
libaio
libnuma1→ 对应
numactl
openssl和
libssl1.1（或
libssl3，取决于 Ubuntu 版本）必须存在 安装命令：
apt-get install -y libaio1 libnuma1 openssl libssl1.1若提示
libtinfo5缺失（常见于 MySQL 5.7 二进制包），需额外安装
libtinfo5（Ubuntu 20.04+ 默认不带）
手动指定 LD_LIBRARY_PATH 仅作临时调试
当无法立刻安装系统包（如受限环境），可临时绕过缺失库检查，但不可用于生产：
确认缺失库路径，例如/opt/mysql/lib/libaio.so.1（自行编译或从其他机器复制） 启动前执行：
export LD_LIBRARY_PATH="/opt/mysql/lib:$LD_LIBRARY_PATH"再运行
mysqld --initialize --user=mysql或
mysqld_safe注意：该方式不解决
numactl这类需调用可执行程序的依赖（
mysqld内部会 exec
numactl），只对纯 .so 加载有效
mysqld --version # 若输出正常，说明依赖已满足；若仍报错，重点检查 error log 中第一行 missing library 名称，它一定是真实缺失项
实际部署中，最常被忽略的是
numactl—— 即使服务器是单 NUMA 节点，MySQL 8.0+ 也会尝试调用它，缺了就静默失败或卡在启动阶段。别只盯着
libaio。
