真正缺失的是动态链接器实际查找的libaio.so.1文件，而非包名libaio1；Ubuntu 24.04已移除该包，需安装libaio1t64并手动创建指向libaio.so.1t64.0.2的软链接，再运行ldconfig生效。
怎么看报错里真正缺的是哪个文件
错误信息里最关键的不是“缺少 libaio”，而是冒号后面那一串——比如 libaio.so.1: cannot open shared object file，这个 libaio.so.1 才是动态链接器实际找不到的符号名。它不等于包名，也不等于你 apt/yum 搜索时看到的包名。
别急着装 libaio1 或 libaio，先确认 mysqld 二进制到底依赖什么：
- 运行
ldd /usr/bin/mysqld | grep "not found"（路径按你实际安装位置调整） - 如果输出里有
libaio.so.1 => not found，那就锁定是这个文件缺失 - 若输出为空但启动仍失败，可能是
numactl调用失败（MySQL 8.0+ 默认会 exec 它），这时要查journalctl -u mysqld -n 50看日志第一行
Ubuntu 24.04 上为什么 apt install libaio1 失败
因为 Ubuntu 24.04 已彻底移除 libaio1 包，只提供 libaio1t64 和 libaio2。而 MySQL 5.7/8.0 的二进制包硬编码依赖 libaio.so.1，不是 libaio.so.1t64.0.2，也不是 libaio.so.2。
此时 apt install libaio1 报 “没有可安装候选” 是正常现象，不是源配置错了，也不是网络问题。
- 不能靠
apt update && apt upgrade解决 - 不能用
libaio2替代——mysqld启动时会直接拒绝加载libaio.so.2 - 正确做法是手动补
libaio.so.1.0.1文件并建软链，再ldconfig
验证 libaio.so.1 是否真能被 mysqld 加载
光把文件放对位置、建好软链还不够。mysqld 启动时得能成功 dlopen()，否则照样报错。
- 执行
ldd /usr/bin/mysqld | grep libaio，输出必须是类似libaio.so.1 => /usr/lib/x86_64-linux-gnu/libaio.so.1 (0x...)，不能是not found - 临时测试：运行
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu /usr/bin/mysqld --version，能输出版本号才说明通路跑通 - 别用
file /usr/bin/mysqld查 ABI——它只告诉你编译时链接了啥，不反映运行时是否真能 resolve
为什么 LD_LIBRARY_PATH 不适合 systemd 服务
systemd 启动 mysqld.service 时默认清空大部分环境变量，LD_LIBRARY_PATH 不会被继承。即使你在 shell 里 export 成功，systemctl start mysqld 还是会失败。
mysqld_safe 内部也会重置环境，所以靠它绕过也不可靠。
- 长期方案只能是把库放进系统标准路径（如
/usr/lib/x86_64-linux-gnu/）并运行ldconfig - 若必须临时调试，可用
systemctl set-environment LD_LIBRARY_PATH=...，但重启后失效，且不推荐用于生产 - 最容易被忽略的是：
numactl缺失不会报libaio错，但会导致 mysqld 卡在启动阶段，日志里可能只显示 “Starting MySQL…” 然后静默退出
