MySQL 8.4 仅支持 CentOS 7.9（即 Linux release 7.9.2009），要求64位系统、glibc ≥ 2.17、内核 ≥ 3.10，不兼容更低版本的 CentOS 7.x。
MySQL 8.4 在 CentOS 7.2009 或内核 io_setup() 直接返回 EAGAIN，连初始化上下文都做不到。
确认是不是真被内核 AIO 限制卡住
别急着改配置或升级内核，先验证问题根源：
- 执行
cat /proc/sys/fs/aio-nr和cat /proc/sys/fs/aio-max-nr：如果aio-nr远低于aio-max-nr（比如 120 vs 65536），说明不是总量不够，而是单进程创建上下文失败 - 查 MySQL 错误日志，确认是否含
io_setup() failed with EAGAIN—— 这是内核级拒绝，和权限、磁盘空间、SELinux 都无关 - 运行
strace -e trace=io_setup,io_destroy -p $(pgrep mysqld)（启动时附加）：若看到反复io_setup(128, ...)后立即-1 EAGAIN，基本锁定为 per-process 上下文限制或内存分配失败 - CentOS 7.2009 内核为
3.10.0-1160.el7，该版本对 AIO 上下文的 per-process 限额极低（默认约 64），且不支持现代 AIO 动态扩容机制
临时绕过：禁用 InnoDB 原生 AIO（最稳）
这是生产环境最快落地的方案，不影响数据一致性，只牺牲少量高并发 I/O 吞吐：
- 编辑 MySQL 配置文件（如
/etc/my.cnf），在[mysqld]段添加：[mysqld] innodb_use_native_aio = OFF
- 确保没有其他地方覆盖该值（例如
my.cnf.d/下的子配置） - 重启前清空
/var/lib/mysql中残留的ib_logfile*和ibdata1（仅首次禁用时需做，避免 AIO 元数据残留冲突） - 执行
systemctl restart mysqld；启动成功后检查日志是否仍有io_setup相关报错
长期适配：调高内核 AIO 限额（需评估风险）
仅当业务确需 AIO 性能、且无法升级内核时考虑。注意：CentOS 7.2009 的 3.10 内核对 aio-max-nr 的实际生效逻辑与新版不同，必须配合资源释放：
- 临时生效（重启丢失）：
sudo sysctl -w fs.aio-max-nr=1048576 - 永久生效：向
/etc/sysctl.conf追加fs.aio-max-nr = 1048576，再运行sudo sysctl -p - 但关键一步常被忽略：MySQL 进程启动前需确保其
RLIMIT_SIGPENDING足够大（AIO 上下文依赖信号队列），在 systemd service 文件中加一行：LimitSIGPENDING=65536
- 同时检查
ulimit -n是否 ≥ 65536，否则io_setup()可能因无法分配事件 fd 而失败
容易被忽略的兼容性细节
即使禁用了 innodb_use_native_aio，仍可能因底层依赖缺失而启动失败：
-
libaio.so.1必须存在：CentOS 7 用yum install -y libaio，装完跑ldconfig -p | grep aio确认输出含libaio.so.1 - MySQL 8.4 二进制包依赖
libnuma.so.1：CentOS 7 需yum install -y numactl，否则报错不提示 AIO，而是静默退出 - 若迁移自较新系统（如 Rocky 9），还可能缺
libcrypt.so.1：CentOS 7 不需要额外装，但若混用镜像，得确认libxcrypt-compat是否已安装 - 禁用 AIO 后，
innodb_read_io_threads和innodb_write_io_threads仍有效，建议设为 4–8（而非默认 4），让同步 I/O 线程更充分并行
真正卡住 MySQL 8.4 在老内核上启动的，从来不是“要不要开 AIO”，而是“开不了时有没有干净地退到同步路径”。禁用参数只是开关，背后依赖链（libaio → numactl → RLIMIT_SIGPENDING）断一环，服务就起不来。
