必须手动创建libaio.so.1软链接才能使mysqld --initialize成功，因Ubuntu 24.04安装libaio1t64后仅提供libaio.so.1t64.0.2，而MySQL硬依赖libaio.so.1，不匹配则进程崩溃并报“cannot open shared object file”。
直接装对包 + 补上软链接，才能让 mysqld --initialize 跑通。光装 libaio1t64 不行，Ubuntu 24.04 和部分国产系统必须手动创建 libaio.so.1 符号链接。
为什么 mysqld --initialize 会卡在 libaio 缺失？
MySQL 启动和初始化阶段硬依赖 libaio.so.1，不是可选优化项。缺失时进程直接崩溃，不写日志、不报详细错误，只输出：error while loading shared libraries: libaio.so.1: cannot open shared object file。这和配置文件语法错误、权限不对等“启动后失败”完全不同——它根本没进 MySQL 逻辑层。
常见诱因包括：
- Ubuntu 24.04 安装
libaio1t64后，实际提供的是libaio.so.1t64.0.2，而非 MySQL 明确检查的libaio.so.1 - CentOS/RHEL 最小化安装未启用 base os 组，
libaio包默认不装 - Alpine 容器中只装了
libaio，但没配好LD_LIBRARY_PATH或路径不在/usr/lib - 手动解压二进制包部署时，误用旧版
mysqld（如 5.7）去跑新系统，或路径错位导致ldd查不到库
Ubuntu 24.04 必须执行的三步验证链
不能只看 apt install 是否成功，要走完下面三步才算真正就绪：
- 确认文件存在：
ls /usr/lib/x86_64-linux-gnu/libaio.so.1—— 应为指向libaio.so.1t64.0.2的软链接 - 确认已入缓存：
ldconfig -p | grep 'libaio\.so\.1$'—— 结尾必须是.so.1，不能多字符 - 确认 mysqld 能解析：
ldd $(which mysqld) | grep libaio—— 输出应形如libaio.so.1 => /usr/lib/x86_64-linux-gnu/libaio.so.1 (0x...)
第三步最容易被忽略：如果 mysqld 在 /usr/local/mysql/bin/mysqld，那就要对那个具体路径执行 ldd，而不是只查 which mysqld 返回的符号链接。
CentOS/RHEL/Alpine 的处理差异
这些系统不会出现 “t64” 命名问题，但包名和命令容易混用：
- CentOS/RHEL 7–9：
yum install -y libaio或dnf install -y libaio，装完即有libaio.so.1 - RHEL 8+ 若启用加密功能，还需
libxcrypt-compat，否则mysqld --initialize静默失败 - Alpine（Docker 场景）：
apk add --no-cache libaio，但注意 Alpine 默认库路径是/usr/lib，若 MySQL 二进制期望/lib，需加ln -sf /usr/lib/libaio.so.1 /lib/libaio.so.1
别用 rpm -ivh --force --nodeps 强行跳过依赖——初始化可能看似成功，但后续写入会静默失败或数据损坏。
numactl 是最常被忽略的隐性依赖
即使服务器是单 NUMA 节点，MySQL 8.0+ 也会尝试调用 numactl。缺了它，mysqld --initialize 可能卡住、无响应、或报错 libnuma.so.1: cannot open shared object file。
补全方式：
- Ubuntu/Debian：
apt install -y numactl libnuma1 - CentOS/RHEL：
yum install -y numactl - 验证：
numactl --show应正常输出 NUMA 配置
别只盯着 libaio——numactl 缺失时，mysqld 可能连错误都不报，直接 hang 住。
