结论：不要在alpine上构建mysql 8.0官方二进制镜像，因musl libc与glibc abi不兼容，导致动态链接失败、解释器缺失（/lib64/ld-linux-x86-64.so.2不存在）、关键函数调用静默崩溃；可靠方案只有三条：使用linuxserver/mysql musl适配镜像、换用alpine原生mariadb，或多阶段构建+非alpine运行时。
直接说结论：不要在 Alpine 上构建 MySQL 8.0 官方二进制镜像，它根本跑不起来——不是配置问题，是 musl libc 和 glibc 的 ABI 不兼容，ldd 显示一堆 not found 是表象，真正崩溃常发生在 SSL 握手或 InnoDB 恢复阶段，且无法稳定复现。
为什么 mysql-8.0.35-linux-glibc2.17-x86_64.tar.xz 在 Alpine 中执行就报 no such file or directory
这不是路径错了，而是动态解释器缺失：/lib64/ld-linux-x86-64.so.2 这个 glibc 自带的 loader 根本不存在于 Alpine。Alpine 只有 /lib/ld-musl-x86_64.so.1。即使你用 apk add glibc-compat 或软链欺骗 ldd，MySQL 启动后仍会在调用 clock_gettime(CLOCK_MONOTONIC_RAW) 或 pthread_atfork 时静默退出（日志里可能只留一行 mysqld: ready for connections 然后消失）。
-
glibc-compat最高只支持 GLIBC_2.14，而 MySQL 8.0.35 要求 GLIBC_2.17+ -
libncurses.so.5在 Alpine 中对应的是ncurses-libs=5.9-r4，装上也解决不了 __libc_start_main 符号缺失 - 强行编译源码？必须全程用 Alpine 的
build-base工具链，并禁用所有 glibc 特有扩展（如-DWITH_SSL=system、-DDEFAULT_CHARSET=utf8mb4），但官方不测试 musl 路径，CI 通过不等于生产可用
真正能用的三条路，按推荐顺序排列
放弃“下载 tar 包解压即用”的幻想，Alpine 上 MySQL 8.0 的唯一可靠路径只有：
- 用社区 musl 编译镜像：
docker pull ghcr.io/linuxserver/mysql:8.0（已预编译适配 musl，含完整 systemd 替代服务管理） - 换 MariaDB（Alpine 原生支持）：
apk add mariadb→mysql_install_db --user=mysql→rc-service mariadb start；MariaDB 10.11+ 功能集已高度兼容 MySQL 8.0 协议和语法 - 多阶段构建 + 官方 MySQL 镜像做运行时基础（非 Alpine）：构建阶段用
mysql:8.0提取二进制和配置，运行阶段切到alpine:3.20并只拷贝mysqld和必要 so（如libcrypt.so.1），但需手动 patch rpath 且不支持插件
apk add mysql 安装的是什么？别当成 MySQL 8.0
Alpine 官方仓库里的 mysql 包其实是 MariaDB 的别名（从 Alpine 3.14 开始）。执行 apk add mysql 实际安装的是 mariadb，版本通常为 10.11.x，mysqld --version 输出会显示 mysqld Ver 10.11.11-MariaDB。它不包含 MySQL 8.0 特有的功能（如角色权限模型、原子 DDL、资源组），但对绝大多数应用层 SQL 兼容。如果你真需要 MySQL 8.0 的特定特性，别绕弯子——直接用 mysql:8.0-oracle 官方镜像，哪怕体积大一倍，也比在 Alpine 上反复调试崩溃强。
最容易被忽略的一点：很多团队以为“用了 Alpine 就一定更安全”，但硬塞 glibc-compat 或自建符号链接反而引入了非标准 ABI 行为，InnoDB 崩溃恢复逻辑在 musl 下未充分验证，线上数据一致性风险远高于镜像体积多出的那几十 MB。
