alpine的musl libc与mysql官方二进制不兼容是根本原因，因二者abi不兼容，导致动态链接失败；推荐使用社区musl适配镜像（如linuxserver/mysql）或alpine原生mariadb，而非强行注入glibc兼容层。
Alpine 的 musl libc 和 MySQL 二进制不兼容是根本原因
MySQL 官方预编译二进制（如 mysql-8.0.35-linux-glibc2.17-x86_64）默认链接 glibc，而 Alpine 使用轻量级的 musl libc。二者 ABI 不兼容，导致 ldd 检查时大量 not found——这不是“少装几个包”能解决的，而是底层运行时不可互换。
常见报错如：error while loading shared libraries: libncurses.so.5: cannot open shared object file、libaio.so.1 not found、甚至直接 exec /usr/bin/mysqld: no such file or directory（本质是解释器路径 /lib64/ld-linux-x86-64.so.2 不存在）。
apk add zlib openssl libstdc++ 不能替代 glibc 运行时
很多人试过 apk add --no-cache zlib openssl libstdc++ libgcc，发现仍启动失败。这是因为：
-
libstdc++和libgcc只提供 C++ 运行时符号，不提供glibc的核心接口（如getaddrinfo、pthread_atfork等） -
zlib、openssl解决的是功能依赖，不是 ABI 层依赖 - 像
libncurses.so.5这类库，在 Alpine 中对应包是ncurses-libs=5.9-r4，但即使装上，MySQL 仍会因找不到glibc的__libc_start_main等符号而崩溃
强行用 glibc-compat 或符号链接绕过风险极高
有人尝试 apk add glibc-compat 或手动建软链：ln -s /usr/lib/libncursesw.so.6 /usr/lib/libncurses.so.5。短期可能“跑起来”，但实际隐患明显：
-
glibc-compat是非官方补丁，版本匹配难，MySQL 8.0.35 需要GLIBC_2.17及以上，Alpine 的glibc-compat通常只到2.14 - 符号链接能骗过
dlopen，但无法解决glibc特有函数缺失（如clock_gettime在 musl 中行为不同） - MySQL 启动后可能在连接池、SSL 握手或 InnoDB 崩溃恢复阶段静默失败
真正可行的路径只有三条，没有“编译安装”捷径
在 Alpine 上让 MySQL 稳定运行，必须放弃“下载 tar.gz + make install”这种通用 Linux 路径：
- 用社区适配镜像：
docker pull ghcr.io/linuxserver/mysql:latest（已预编译为 musl，含完整服务端） - 改用原生支持 Alpine 的
mariadb：apk add mariadb→mysql_install_db→rc-service mariadb start - 源码编译（仅限可控项目）：必须指定
-DWITH_SSL=system、-DDEFAULT_CHARSET=utf8mb4，且全程用 Alpine 的build-base工具链，避免混入 host 的 glibc 头文件
最常被忽略的一点：哪怕选了 mariadb，也要注意 /etc/my.cnf.d/server.cnf 中禁用 skip-external-locking（musl 下文件锁语义不同），否则高并发下可能丢数据。
