不要在Alpine上运行MySQL 8.0官方二进制包，因musl与glibc ABI不兼容，导致动态解释器缺失、关键函数调用静默崩溃；可靠方案仅三条：使用linuxserver/mysql musl镜像、换用Alpine原生MariaDB，或多阶段构建+非Alpine运行时。
别在 Alpine 上直接跑 MySQL 8.0 官方二进制包——它根本不会真正启动，不是配置错，是 musl 和 glibc ABI 层面不兼容。
为什么 mysql-8.0.x-linux-glibc2.17-x86_64.tar.xz 在 Alpine 中报 “no such file or directory”
这不是路径写错了，而是动态解释器缺失：/lib64/ld-linux-x86-64.so.2 根本不存在于 Alpine。Alpine 只有 /lib/ld-musl-x86_64.so.1。即使你用 apk add glibc-compat 或软链骗过 ldd，MySQL 启动后仍会在 SSL 握手、InnoDB 恢复或调用 clock_gettime(CLOCK_MONOTONIC_RAW) 时静默退出——日志里可能只留一行 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），但官方不测试 musl 路径，CI 通过 ≠ 生产可用
alpine:latest + apk add mysql 实际安装的是 MariaDB
从 Alpine 3.14 开始，apk add mysql 是个 alias，实际安装的是 mariadb（通常为 10.11.x）。它能跑，但不是 MySQL 8.0：
- 协议和语法高度兼容，
mysql-client连接无感知 - 不支持 MySQL 8.0 特有功能：角色管理、原子 DDL、新的 JSON 函数、caching_sha2_password 默认认证插件
- 如果你的应用依赖
caching_sha2_password或服务端 RSA 密钥交换，MariaDB 会直接拒绝连接
真正可行的三条路（按推荐顺序）
放弃“下载 tar 包解压即用”的幻想，Alpine 上 MySQL 8.0 的唯一可靠路径只有：
- 用社区 musl 编译镜像：
docker pull ghcr.io/linuxserver/mysql:8.0—— 已预编译适配 musl，含完整服务管理逻辑，支持caching_sha2_password和 SSL - 换 MariaDB：
apk add mariadb→mysql_install_db --user=mysql→rc-service mariadb start—— 仅适用于不强依赖 MySQL 8.0 新特性的场景 - 多阶段构建 + 非-Alpine 运行时：
FROM mysql:8.0提取mysqld和必要 so（如libcrypt.so.1），再COPY到alpine:3.20，但需手动 patch rpath 且无法加载插件（如component_validate_password）
MySQL 客户端镜像可以放心用 Alpine
客户端工具（mysql, mysqladmin）本身不依赖 glibc 特有符号，musl 完全能跑：
FROM alpine:3.20 RUN apk add --no-cache mysql-client ENTRYPOINT ["mysql"]
这种镜像体积稳定在 12–15MB，适合 CI/CD 中做数据库健康检查或批量执行 SQL；但注意：mysql-client 版本要 ≥ 8.0 才能正确处理 caching_sha2_password 认证流程，旧版会卡在握手阶段。
musl libc 和 glibc 的 ABI 不兼容是硬边界，不是靠加几个包、改几行 Dockerfile 就能绕开的。最容易被忽略的点是：崩溃往往不报错，只在关键路径（如首次建表、SSL 连接、binlog 切换）静默退出——等你发现时，数据可能已处于不一致状态。
